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SZÓTÁR 


3. RÉSZ 





Szókincsbővítés ? 

A napokban ismét felmerült egy olyan 
kérdés, melyet már sokszor megrág- 
tunk, ez pedig a szókincs alakulása. 
Gondolok itt arra, hogy miként változ- 
tatja meg egy szakma a nyelv szókin- 
csét, illetve viszont. Az informatika 
világában ez különösen érezhető, 
hiszen egy rendkívül gyorsan változó 
területről van szó, gondoljunk csak 
bele, egy-két év alatt annyi új fogalom 
kerül be a szakmába, amennyi tíz év 
alatt nem született meg egy fél évszá- 
zaddal ezelőtt. 

A kérdés tehát nem az, hogy szükség 
van-e új fogalmakra, sokkal inkább 

az, hogy hogyan , kereszteljük el" őket. 
Ha felmerül egy új (többnyire angol) 
fogalom, a magyarításának általában 
két útja van. Az első változat, amikor 
az angol szó ,könnyen kimondható" 
(megjegyzem, más mondható ki köny- 
nyen egy angolul tudó informatikus- 
nak, mint egy átlagembernek). Ekkor 

a szó magyarításán a tömeg nem is 
agyal - nagy örömmel és némi gőgös 
büszkeséggel használják a beszédben 
az angol szót. Később jönnek a gondok, 
amikor le kell írni, mert hogyan is írjuk 
le, hogy key-jel, vagy hogy array-ben? 
És ha eddig sem született , elég vagány" 
fordítás, akkor bizony a magyar nyelv 
szabályai alapján szembejönnek 

majd a domének, a rúterek, a flopik 
meg az ofiszok. 

A második lehetőség, ha , nem mond- 
ható ki könnyen", egy kicsit kemé- 
nyebb dió, hiszen itt már az első pilla- 
nattól fogva még a hunglist beszélők 
is komoly igényt éreznek egy megfe- 
lelő szó használatára. Nagyon rövid 
ideig tartott a vita a billentyűzet körül 
(senki sem kívánja, hogy a kíbordon 
kelljen dolgoznia, de sokáig tartották 
magukat a klaviatúrapártiak), és alig 
gondolkodik el az ember, hogy mauz 
vagy egér. 

Gyakran emlegetett érv az új jövevény- 
szavak mellett, hogy , az új szavakkal 
bővítjük a szókincset". Ez az a pont, 
ahol komolyan elgondolkodom. Mert 
ha valaki szveppel a diszken, ha log- 
golja, amit csinál, és lagzik, ha nem éri 
utol magát, akkor biztos, hogy sok , új 
szót" használ, de vajon az illető szókin- 
cse hosszú távon egészséges és kerek 
marad-e. lovábbra is használni fogja-e 
a színes magyar szókincs ugyanazokra 


a fogalmakra illeszkedő tagjait? Kiala- 
kul-e egyáltalán egy széles szókincs 
ilyen tolvajnyelv mellett? 


AP - elérési pont 

acces point 7 elérési pont 

arányos szélességű — proportional: 
olyan betűkészlet, melynél a betűk 
egyedi szélességgel rendelkeznek, 
tehát például négy M betű egymás 
mellett lényegesen több helyet foglal, 
mint négy I betű. 

bérlés — leasing: olyan versenyhelyzet- 
kezelési módszer, amikor nem történik 
tényleges zárolás, de versenyhelyzet 
alapján a rendszer a bérlőnek üzenetet 
küld, miszerint is a , bérlemény meg- 
szűnt", egy másik folyamat változtat 
az erőforráson. 

ciklus - loop: programszervezési elem 
valamilyen feltétel alapján többször 
végrehajtandó programrészlethez. 
címke - tag: több értelemben használ- 
juk, az angol tag szó fordításaként a 
jelölőnyelvek (például html, xm!l stb.) 
egyes vezérlésre, tulajdonság-meghatá- 
rozásra használt elemei. Használják 

rá a magyar tag szót is (taggal, tagok), 
értelmileg a címke pontosabb. 

context menu 7 helyi menü 

fibre channel - rostcsatorna 

fogantyú 7 handle: grafikai elemeket 
kezelő programoknál egy grafikai 
objektum kitüntetett pontjai (általában 
kis négyzetekkel jelölve), melyek 
segítségével különböző módosításokat 
végezhetünk (nyújtás, forgatás, átmé- 
retezés stb.). 

handle — (1.) kezelő, 2 (2.) fogantyú 
helyi ment — context menu: programok- 
ban adott elemekhez tartozó menü, 
melyet például a jobb egérgombbal 
kattintva hívhatunk elő. 

hivatkozás — link: (1.) egy hálózati 
erőforrásra mutató elem, melyhez akár 
tevékenységeket is lehet rendelni 
(például böngészőben a hivatkozáson 
való kattintáshoz), (2.) a fájlrendszeren 
belül egy In paranccsal létrehozott fájl, 
mely lehet közvetett (direct, hard) és 
közvetlen (symbolic, soft). A közvetlen 
hivatkozás valójában az adott fájl tar- 
talmához létrehozott újabb fájlrendszer- 
bejegyzés, külön fájlként viselkedik, 
míg a közvetett hivatkozás csupán 

a másik fájlbejegyzésre mutat. 

elérési pont — access point, AP: vezeték 


nélküli hálózatoknál azok az eszközök, 
melyek hozzáférést biztosítanak az 
adott hálózathoz. 

hurokeszköz - loop device: egy olyan 
hálózati csatoló, mely csak elméleti 
szinten létezik, közvetlen visszacsatolás 
( hurok") a gépre. 

imagemap 7 képtérkép 

képtérkép — imagemap: elsősorban 
weboldalakon használt ábrák, melyek- 
hez egy ,térkép" tartozik, mely meg- 
adja, hogy a kép különböző területein 
kattintva milyen tevékenységet kell 

a rendszernek végeznie. 

kezelő — handle: programozásban a 
megnyitott fájlokat a kódon belül gyak- 
ran egy változóban tárolt értékkel 
tartjuk nyilván, ez a fájl kezelője vagy 
kezelőszáma. 

lease, leasing 7 bérlés 

link 7 (1.) összeszerkesztés, 2 

(2.) hivatkozás, 7 (3.) összekötés 

loop — (1.) ciklus, 2 (2.) hurokeszköz 
monospaced - rögzített szélességű 
nullmásolás -— zero copy: a forrás és a 
cél közötti közvetlen másolás módszere. 
Például egy fájl tartalmának egy esz- 
közre küldése több egymás utáni máso- 
lást igényel, ezek áthidalására használ- 
ható egyetlen művelet. Lásd bővebben 
az 54. oldalon található cikket. 
összeszerkesztés —- link: a programfor- 
dítás utolsó lépése, amikor a lefordított 
programrészeket egy egységes állo- 
mánnyá állítjuk össze. 

összekötés - link: eszközök, elemek 
közötti kapcsolat kialakítása. 
proportional - arányos szélességű 
rostcsatorna -— fibre channel: egy átviteli 
eszköztípus, pontosabban egy átfogó 
protokoll- és átviteli felületmeghatá- 
rozás, a rostcsatorna célja, hogy egysé- 
ges és gyors felületet biztosítson külön- 
böző elemek (akár a gép alkatrészei, 
akár önálló gépek) között. Löbb érte- 
lemben is használják. 

A 3 http:/hsi.web.cern.ch/HSI/fcs/ 

2 http:/wwwiiol.unh.edu/training/ 
fc/fc tutorial.html 

2 http:/www.fibrechannel.org/ 
címeken bővebb tájékoztatás olvasható. 
rögzített szélességű — monospaced: olyan 
betűkészlet, melynek mindegyik karak- 
tere azonos szélességű (a karakterhez 
tartozó térközzel együtt). Lásd még: 
arányos szélességű. 

tag 7 címke 

zero copy 7 nullmásolás. 
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Szy György 

a Linuxvilág főszerkesztője, 

a Kiskapu Kiadó vezetője. 
Mindenki levelét örömmel 
várja a következő levélcímen: 
Szy. Gyorgy Olinuxvilag. hu 


Azt mondják, tavasszal a termé- 
szet felébred, ilyenkor kap min- 
denki új erőre. A tavasz ereje a 
linuxos közösségben is érződik, 
számos olyan változás történt és 
történik a napokban, melyek 
hosszú távon éreztetik majd a 
hatásukat. Ott van például az 

új FSF alapítvány , létrejötte" . 
Azért használtam idézőjeleket, 
mert a csapat valójában hosz- 
szabb ideje létezik, de csak a na- 
pokban történt meg az alapít- 
vány bejegyzése. Ha valaki eset- 
leg nem tudná hova tenni a csa- 
pat tagjait, nézzen körbe 
például az OpenOffice.org fordítói 
hétvégén résztvevők között. 

Ezzel szinte egy időben lezajlott az LME 
rendszeres éves választmányi gyűlése is. 
Illetve nem is biztos, hogy helyesen fo- 
galmazok, amikor rendszeres éves gyű- 
lésről beszélek, hiszen az egyik legfon- 
tosabb meghozott döntés éppen az volt, 
hogy ne egy, hanem három évre válasz- 
szák meg az elnökséget, valamint az 
ellenőrző bizottságot. 

Ezzel a két történéssel kapcsolatban csak 
nem tudom megállni, hogy hangosan el 
ne gondolkozzam. Az elmúlt években 
láthattuk, hogy bizony nagyon komoly 
igénye van a linuxos közösségnek a kép- 
viseletre, az érdekvédelemre és a rek- 
lámra. Bár vannak kisebb csoportok, akik 
a Saját ,onzáskörzetükben" tevékeny- 
kednek, de eleddig hiányoltam azt 

a szervezetet, amelyik elég erős és — 
mondjuk így - elég rámenős, hogy fel 
tudja venni az üzleti alapokon működő 
ellenfelekkel a harcot. 

Ahogy azt már régebben is papírra 
vetettem, az LME-től vártam volna el, 
hogy az országos összefogás létrejöjjön, 
és az ország különböző pontjain lévő 
csoportok között erősítse kapcsolatot. 
Azt gondolom, hogy sajnos még mindig 
a turáni átok ül a linuxosokon is, és — bár 
ne legyen igazam — könnyen lehet, hogy 


a több szakmai szervezet nem segíteni 
fogja az előbb említett célt, hanem 
éppen ellenkezőleg. Csak abban bízom, 
hogy ez a ,megerősödési időszak" minél 
gyorsabban, minél fájdalommenteseb- 
ben zajlik le, és hamarosan tényleg erős 
képviselet lesz — számomra mindegy, 
hogy egy szervezet vagy tíz, a lényeg, 
hogy hatékonyan működjön. 

Szóval tavasz és kikelet. Nálunk is több 
huncutság gyűlt össze erre a lapszámra. 
Nem csak arra gondolok, hogy két gép 
találta ki lapzárta közben, hogy ők nem 
hajlandóak tovább folytatni a robotmun- 
kát, meg nem is arra, hogy a nyomdába 
adás napján derült ki több oldalról, 
hogy nincs meg, sokkal inkább például 
nyugtalan grafikusunkra, aki — meglátva 
a gimpes cikket, megviccelte egy kicsit 
olvasóinkat. Ha alaposabban megnézi- 
tek a cikkben található babát, hogy mit 
is olvas, látjátok majd, mire gondolok. 
Új tervem is szép lassan körvonalazódik 
a nyílt forrású ,vállalatirányítási rend- 
szerről", a múlt havi számban megjelent 
cikkem kapcsán többen jelentkeztek, és 
remélem, hogy hamarosan egy komo- 
lyabb találkozót hozhatunk össze. 

Az már sejthető, hogy egy olyan modu- 
los felépítésű rendszert kell kialakítsunk, 
ami a felhasználó igényeitől függően a 
különböző rétegeket (például raktárke- 
zelés, partnernyilvántartás, rendelések 
stb.) tetszőleges mélységben kezeli, de 

a szolgáltatásokat mindenhol megtartja. 
Komoly kihívás lehet például, hogy ahol 
nem foglalkoznak engedményekkel, ott 
ne kelljen a felhasználónak bajlódnia a 
felesleges adatok kitöltésével, mindezek 
ellenére a rendszer egységes maradjon. 
No, de erről majd a következő számban 
írok részletesebben. Addig is várom 
mindenki levelét, aki — akár vállalat 
nevében, akár szakemberként - szívesen 
részt vesz a fejlesztésben. 

A márciusi számhoz is kellemes olvas- 
gatást kívánok, remélem, mindenki talál 
benne kedvére valót! 
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Programvadászat 


assan itt a tavasz -— télen, a számí- 
L tógép előtt ülve elgémberedett 
tagjainkat ideje kinyújtóztatnunk, 
a korongról frissíteni a Linuxunkat, 
szétnézni az Interneten frissítésekért 
és biztonsági javításokért. Javítsuk ki 
a hibákat, és menjünk ki a levegőre 
- magára hagyva az oly sokat kényez- 
tetett vasszörnyeteget. Mint mindennek, 
a számítógépnek is van azonban lelke, 
még ha ezt néha tagadjuk is, úgyhogy 
egyelőre ne hagyjuk túl sokáig magára, 
nehogy megsértődjön. A további idő- 
töltéshez pedig kiváló segítséget fog 
nyújtani az MPlayer és a Gimp. 


MPlayer 


Ez méltán népszerű, és nekünk, magya- 
roknak különösen szívmelengető, hatal- 
mas tudású médialejátszó programnak 
a legfrissebb változata (0.90rc4) került 
fel korongunkra. Ez az utolsó RC kiadás, 
a következő csomag már 0.90 névre 

fog hallgatni. 





Nézzük meg - a teljesség igénye 

nélkül -, hogy mi változott: 

e  -ac hwac3 kijavítva (az rc3-ban 
rossz volt) 

e vo svga: 4bpp- és $bpp-javítás 

e javítva a ./configure --cc—"ccache 
gcc" hiba 

e  -loop-javítások, így a -loop 2 tényleg 
kétszer játszik 

e mp3lib: layer-2-dekódolásjavítások 

e  libavcodec: DivX 5.03-dekódolás 

e ao oss: korlátozott csatornakezelés 
javítva 

e vorbis dekódolás kijavítva 

e -ao mpegpes Tt -ac hwac3 kijavítva 

e -ao pcm bogus wav fejléc javítva 

e -voxl1- -wid javítva 

e  sig11 a második hangfájl 
lejátszásánál — javítva 
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e configure: cdda, nas, ilőn, svgalib, 
faad2, lame felismerés javítva 

e — -af/-af-adv támogatás a mencoderben 

e  libmpdvdkit2: frissítve libdvdcss 
1.2.5-re 


Újdonságok: 

e  nyersvideo-támogatás (-rawvideo, 
hasonlít a -rawaudio-ra) 

e — kísérleti mpeg4-es támogatás 
(bekapcsolása a -demuxer 27 -íps xxx 
kapcsolóval) 

e . dvd/vobsub-fejlesztések: 
pozícionálás, választható Gauss 
életlenítés (gaussian blur scaler) 

e — vf bmovIl: 40090-os sebességnövekedés 

e  libavcodec: natív DV audiodekóder 

e GIF demuxer (animált GIF-ekhez) 

e új Zzajeltávolító szr: -vop denoise3d 

e . gamma és MMX-hez javított 
fényerősség stb. 

e támogatás a -vop eg2-ben 

e a xvid és divx4/5linux könyvtárak 
egy idejű támogatása 

e  libavcodec: néhány B-frame-mel 
kapcsolatos enkódolási hiba javítva 


Blender 3D 


Miután a Blender 3D szerkesztőprogram 
jövője megnyugtatóan eldőlt, forrását 

a fejlesztői nyílttá tették. Ezentúl a nép- 
szerű 3D-modellező, animációs és leké- 
pezőprogramot készítő cég nonprofit 
alapítványként (Blender Foundation) 
folytatja működését. Az alapítvány 
emellett egy e-boltot is üzemeltet, 
amelyben könyvek és egyéb kiegészítők 
kaphatók a Blenderhez. 

A tulajdonosok a Blender teljes forrás- 
kódját a GNU GPL felhasználási szerző- 
dés alatt hozták a nyilvánosságra, és a 
weboldalon lehetőséget teremtenek a 
Blender köré egy, az egész világra kiter- 
jedő fejlesztői közösség kialakulására. 

Ez természetesen nagymértékben előse- 
gítheti a Blender további fejlődését. Már 
most is egy igen nagy tudású és megbíz- 
ható modellező-, animációs és leképe- 
zőrendszerhez van szerencsénk. A for- 
ráskód nyílttá tételével rengeteg fejlesz- 
tőhöz eljutottak, így a Blender rajongó- 
táborából kikerülő programozók belevet- 
hetik magukat kedvenc rendszerük 
fejlesztésébe. A japán változat — mint 

a képen láthatjuk — már el is készült. 

A program a 45. CD Blender könyvtárá- 











ban található, több operációs rendszerre 
előre fordított csomagban. 


Gimp 

A legújabb kiadása, vagyis az 1.2.3-es 
megbízható és a 1.3.11-es fejlesztői 
változat forráskódja és egyéb kiegészí- 
tők kaptak helyet a korongon a Gimp 
könyvtárban. 





OpenOffice.org 1.0.2 
Az egyik legjobban használható linuxos 


irodai csomag új változata is helyet 
kapott a CD-n — mind előre lefordított, 
azonnal telepíthető, mind forráskód 
formájában megtalálható korongunkon. 
A forráskódot azoknak ajánljuk, akik 
egy kicsit belülről is szeretnék megis- 
merni ezt a nagyszerű programot. 

A sok bosszantó hibát a készítők már 
kijavították. 

A rendszermagfa változásait is közzé 
tesszük a fejlesztői rendszermag és a 
különféle foltok formájában. lermésze- 
tesen a Magazin könyvtárban a kapcso- 
lódó anyagok ugyancsak megtalálhatók. 


Csontos Gyula 
(Csontos.Gyulaolinuxvilag.hu) 
A Linuxvilág szakmai és 
CD-szerkesztője. Szabadide- 
jében szívesen mászik hegyet 
és kerékpározik. 


NITROX, az új biztonsági lapka 

Az ABII legújabb kiszolgálókba szánt 
alaplapjára különleges biztonsági lapka 
került. A Cavium Networks NIIROX 
Security Macro Processor nevű egysége 
400 Mb/s sebességű IPSec-forgalmat 
képes támogatni, vagy 3500 RSA műve- 
let elvégzésére képes másodpercenként. 
Az alaplapot elsősorban egy egység 





magas, állványra szerelhető számítógé- 
pekbe szánják, amelyek például VPN- 
átjáróként vagy SSL-kapcsolatokat nagy 
számban fogadó webkiszolgálóként 
alkalmazhatók. Az alaplapon a különle- 
ges processzor mellett nem sok dolgot 
találunk: a memória és a Pentium 4 pro- 
cesszorok fogadására képes foglalatok 
mellett egy szál PCI-foglalat árválkodik, 
mellette két ethernetcsatoló, egy PS/2 
aljzat, egy soros és egy párhuzamos 
kapu, illetve némi USB-szórvány teremt 
lehetőséget a külvilággal való kapcsolat- 
tartásra; képet a szintén az alaplapra 
épített VGA-vezérlőn keresztül kapunk. 
Az Abit a közeljövőben hasonló, de több 
processzor fogadására képes alaplapot is 
tervez megjelentetni. A nagyobb teljesít- 
ményű változatra Gigabit ethernetve- 
zérlő kerül majd, illetve a nagyobb se- 
bességű hálózati forgalom támogatá- 
sához is elegendő teljesítményt nyújtó 
NIIROX lapka. 

2 http:/www.abit.com.tw 


Portocom-nehézségek 

Egymilliárd forintos csempészés vádjá- 
val előzetes letartóztatásba helyezték 

a Portocom Rt. négy vezetőjét. A felje- 
lentés szerint a cég egy olyan vállalko- 
zástól vásárolt számítógép-alkatrésze- 
ket, ami értéken alul vámkezeltette 
azokat. A Portocom közleménye szerint 
a Vám- és Pénzügyőrség Országos 
Parancsnoksága már három éve vizs- 
gálja a vállalkozás működését, de sza- 
bálytalanságot nem talált, ellenben 
jogosulatlanul igénybe vett vámked- 
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vezmények gyanúja miatt az ügyészség 
elrendelte a négy érintett személy őri- 
zetbe vételét. A Portocom szerint a fel- 
jelentés hátterében egy a cég jelentős 
piaci részesedésére áhítozó versenytár- 
suk áll, amely így szeretné kiütni a nye- 
regből a hordozható gépek magyaror- 
szági piacának egyik meghatározó 
szereplőjét. A Portocom működését 

az ügy nem befolyásolja. 


Bio-üzemanyagcellák 

A Sharp és a RIIE kutatóintézet közös 
bejelentése szerint a két szervezet kifej- 
lesztette azokat az alapmegoldásokat, 
amelyek révén a jövőben bio-üzem- 
anyagcellákat építhetnek. A cellák egy 
, hagyományos" üzemanyagcellából, 
illetve egy mikrobákat tartalmazó egy- 
ségből fognak állni. Az utóbbi feladata 
az, hogy cseppfolyósított és finomított 
konyhai hulladékból származó glükózt 
feldolgozva hidrogént termeljen, ame- 
lyet az üzemanyagcellához vezetnek, 
így nem lesz szükség külön hidrogén-, 
metanol vagy egyéb gázforrásra, mint 
a már meglévő megoldásoknál. A bio- 
cellák kisméretűek lesznek, egy match- 
box nagyságú készülék egy LCD IV-t, 
egy kétliteres egység pedig egy egész 
háztartást képes lesz táplálni. 

A kutatás során a legnagyobb gondot az 
jelentette, hogy a korábbi hasonló meg- 
oldásoknál a mikrobák túlságosan kevés 
hidrogént termeltek. Módosításukkal 
sikerült elérni, hogy hosszabb ideig 
éljenek, és több százszor hatékonyabb 
hidrogéntermelést folytassanak. 

2 http:/www.rite.or.jp 


Első magyar PHP Konferencia 
2003. március 29-én a PHP-levelezőlista 
közössége és az ELIE Radnóti Miklós 


Gyakorlóiskola megren- 


Konferenciát. A rendez- 
vényen a részvétel ingye- 
nes lesz, a szervezők 
egyaránt várják a számítástechnikai 
cégek döntéshozó vezetőit, a progra- 
mozókat, az érdeklődő tanárokat és 
diákokat; illetve általában mindenkit, 
akit érdekel a webes fejlesztések téma- 
köre. A számítógépes partik hangulatát 
idézi az 5k compo megrendezése, 
amelyre legfeljebb 5120 bájt méretű, 
tetszőleges célt szolgáló programmal 
lehet nevezni — a verseny győztesei 
webtárhely-szolgáltatást, folyóirat-előfi- 
zetéseket és könyvet nyernek. (Erről 
bővebben lásd a 14. oldalon beszélgeté- 
sünket a szervezőkkel.) 

2 http:/www.phpcontf.hu 





dezi az Első Magyar PHP 


Csődbe került a telnet? 


Lapzárta előtt nem sokkal szinte robbant 
a hír: csődvédelembe menekült a telnet 
Magyarország Rt. A cég honlapján több 
mint féléves a legújabb sajtóközlemény, 
nem mondhatjuk el tehát, hogy buzgón 
cáfolnák a saját összeomlásukkal kap- 
csolatos híreket. A telnet által üzemel- 
tetett weblapok a hírek szerint egy időre 
elérhetetlenné váltak, külföldi vonalait 
lekapcsolták, szolgáltatásai leálltak, 
ügyfélszolgálatán a telefont nem veszik 
fel — ha tehát esetleg kiderülne, hogy az 
internet magyarországi történetének 
egyik szinte kultikussá vált szereplője 
háza táján minden rendben van, hírne- 
vének és ügyfélkörének semmiképpen 
nem tettek jót a történtek. 


Új Lindows-termékek 

A Lindows.com legújabb terméke újabb 
köntösbe bújtatva próbálja meg a fel- 
használók asztalára csempészni a Lin- 
dows operációs rendszert. A cég sajtó- 
közleménye szerint a Lindows Media 


iMedia 


Computar 





Computer különféle szórakoztató elekt- 
ronikai készülékek egész halmazát 
tüntetheti el tulajdonosa lakásából, aki 
egyetlen olcsó számítógép megvásár- 
lásával kiválthatja az otthoni CD-, 
MP3- és DVD-lejátszót is. A mindössze 
10 másodperc alatt elinduló gép képer- 
nyőjén a felhasználónak elegendő azt 
kiválasztania, hogy éppen mit szeretne 
nézni-hallgatni, majd a multimédiás 
billentyűzettel és az egérrel könnyedén 
eligazodhat a képernyőn megjelenő 
kezelőszervek között. Ezeket a lehetősé- 
geket az Elegent nevű cég etbVD meg- 
oldása, a gép BIOS-ába ágyazott DVD- 
lejátszó program teszi elérhetővé. Ha 

a felhasználónak mégis egy normál 
számítógépre volna szüksége, egyetlen 
kattintással elindíthatja és megjelenít- 
heti a LindowsOS szokványos felületét, 
és játszhat, internetezhet, szöveget 
szerkeszthet. 

A viszonylag kis méretű, VIA C3 pro- 
cesszorral, DVD-meghajtóval és ether- 
netcsatolóval felszerelt gépet a tengeren- 
túli vásárolók 350 dolláros áron vásárol- 
hatják meg, amivel a -— tulajdonképpen 
semmi különlegességre nem képes, 
mégis figyelemre méltó — Lindows 
Media Computer szinte az eldobható 
termékek árszintjére lépett le. 

2 http:/www.elegent.com 
info.lindows.com/Ilmc 


2003. március 1 


11111 JEZZÁTTZZTT 


0 Kiskapu Kft. Minden jog fenntartva 


KT 





0 Kiskapu Kft. Minden jog fenntartva 


Uj Sony fájlkiszolgáló 

A Sony új fájlkiszolgálója nagyjából 
akkora, mint egy nagyobb zsebrádió, 
mégis rögvest két feladatra is alkalmas: 
egyrészt egy 2,5"-os merevlemez révén 
fájlkiszolgálóként használható, másrészt 
vezeték nélküli 
hálózati hozzáférési 
pontként szolgál. 

A fájlkiszolgáló fo- 
galma hagyomá- 
nyosan valamilyen 
nagyméretű, szigo- 
rúan helyhez kötött 
gépet takar — itt azonban messze nem 
erről van szó. A készülék beépített ak- 
kumulátorával egy órán át tud üzemel- 
ni, ha pedig elektromos hálózat van a 
közelben, akkor a bölcsőjébe helyezve 
tetszőleges ideig rendelkezésre áll, illet- 
ve ilyen módon vezetékes hálózathoz is 
csatlakoztatható. lermészetesen igazi 
hordozhatóságról a csekély akkumulá- 
toros üzemidő miatt még nem beszél- 
hetünk, de olyan helyzetekben, amikor 
rövidebb időre — például egy megbeszé- 
lés idejére — vezeték nélküli hálózatot 
kell létrehozni és fájlokat kell megosz- 
tani, a készülék hasznos segítőtárs lehet. 
Operációs rendszere Linux, egyszerre 
akár 250 ügyfelet is ki tud szolgálni, a 
fájlok továbbítását CIFS/SMB és NFSv3 
protokoll felett végzi. 


BEA Weblogic Itanium 2 alapon 

A BEA WebLogic kiszolgáló 2002. feb- 
ruár 12-től a Hewlett-Packard HP-UX 
1i v 1.6 operációs rendszerrel dolgozó 
Itanium 2 alapú kiszolgálógépein is fut- 
tatható. Az Ítanium szerkezetnek kö- 
szönhetően az ügyfelek és a rendszer- 
integrátorok a korábbinál gyorsabban 
végezhetik el a régebbi és a webalapú 
alkalmazások összevonását, és ily 
módon nagyobb hatékonyságot és jobb 
válaszsebességet érhetnek el. 

A HP Itanium alapú kiszolgálóinak 
széles kínálatából választó nagyvállala- 
tok, független programszállítók (ISV-k) 
és rendszerintegrátorok - jelenleg HP- 
UX, illetve néhány hónapon belül Linux 
és Windows operációs környezetben is — 
hatékonyan hozhatják létre és vonhatják 
össze üzleti alkalmazásaikat és web- 
szolgáltatásaikat. A BEA és a HP közös 
munkája nyomán várhatóan tovább 
gyorsul az Itanium alapú megoldások 
elterjedésének üteme, és a két cég ügy- 
feleit még inkább hozzá tudja segíteni 
az Itanium szerkezetben rejlő előnyök: 

a kedvező ár-teljesítmény-arány, a nagy 
teljesítmény és kapacitás kiaknázásához. 
2 http:/www.hp.hu 
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Fujitsu-Intel-együttműködés 

A Fujitsu és az Intel bejelentették, hogy 
a jövőben közösen fejlesztenek csúcska- 
tegóriájú vállalati kiszolgálókat. Az új 
Linux vagy Windows operációs rend- 
szert futtató gépek a Fujitsu nagygépes 
és Unix alapú kínálatát fogják kiegészí- 
teni, így a cég minden területre megfe- 
lelő megoldást tud majd kínálni 
ügyfeleinek. 

Az együttműködés eredményeként 
2004 végére Intel Xeon alapú kiszolgálók 
jelennek meg a Fujitsu kínálatában, 2005 
végére pedig akár 128 Intel Itanium 
processzort tartalmazó monstrumot is 
vásárolhatunk tőle. 

Az együttműködés segítése, illetve 
októberben bejelentett linuxos tervei 
támogatására a Fujitsu egy új, kifejezet- 
ten linuxos rendszerekkel foglalkozó 
üzleti részleget is létrehozott. A több 
mint háromszáz mérnököt foglalkoztató 
részleg a Fujitsu nagy megbízhatóságú 
rendszerek építésében szerzett tudására 
építve biztonságos, nagy rendelkezésre 
állást és méretezhetőséget biztosító 
számítógépeket, valamint alapfeladatok 
elvégzésére alkalmas programokat fog 
fejleszteni. 

2 http:/www.fujitsu.com 

2 http:/wwwiintel.com 


Xandros Desktop 1.0 
A Xandros kiadta az 
ex-Corel Linux ham- 
vain szárba szökkent 
Xandros Desktop 1.0 rendszerének 
Standard Edition névre keresztelt 
változatát, amely lényegében a mostani 
bejelentéssel Deluxe változattá 
előléptetett Xandros Desktop 1.0 kissé 
lebutított változata. A Standard Edition 
is tartalmazza a Xandros előnévvel 
ellátott összetevőket, mint az Installer, az 
Enhanced Desktop és a File Manager, 
irodai feladatokra az OpenOffice.org, 
böngészésre pedig a Mozilla áll hasz- 
nálói rendelkezésére. A Deluxe válto- 
zattal ellentétben viszont telepítője nem 
tudja átméretezni a már meglévő NIFS- 
lemezrészeket, hogy helyet szorítson az 
újabb operációs rendszernek, nem 
tartalmazza a CodeWeavers CrossOver 
Office és Plugin termékeket, nem jár 
hozzá nyomtatott kézikönyv, és a vásár- 
lónak mindössze egyetlen alkalommal 
van joga - elektronikus levélben — 
támogatást kérni. A sok nem mellett 
némi vigaszt jelenthet, hogy így 5 cent- 
tel 40 dollár alá süllyedt a rendszer ára, 
ami tulajdonképpen barátinak is 
mondható. 

2 http:/www.xandros.com/ 
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Bajban a Mandrake j 
Január közepén röppent Cr 
fel a hír, hogy a francia 

MandrakeSoft, a Mandrake Linux- 
terjesztések készítője csődvédelmet 
kért a helyi bíróságtól. Szerencsére 

szó sincs arról, hogy el kellene siratni 

a céget, egyszerűen , csak" annyi tör- 
tént, hogy a MandrakeSoft nem tudja 
teljesíteni kötelezettségeit — vagyis nem 
tud fizetni a hitelezőinek. A cég mű- 
ködése nem állt le, tartozásait pedig 
megpróbálja átütemezni, újratárgyalni 
a hitelezőkkel. A megfelelő átszervezé- 
sek és a pénzügyi egyeztetések után 

a MandrakeSoft jó eséllyel talpra állhat. 
Derűlátásra ad okot például, hogy a 
cég az utóbbi időben eredményesen 
csökkentette működési költségeit és 
növelte bevételeit; igaz, nyereséget 
ennek ellenére sem termelt. 

A 5 http:/www.mandrake.com oldalra 
látogatva nyomát sem látni annak, 
hogy történt valami: február elején 
elérhetővé vált az áprilisra várható 
9.1-es terjesztés harmadik próbavál- 
tozata és a Mandrake Corporate Server 
2.1 összeállítás is. 





Működés közbeni rendszerírissítések 
Az alkatrész- és programfrissítések, 
illetve a szükséges felügyeleti feladatok 
elvégzése érdekében sok cégnél elke- 
rülhetetlenek a tervezett rendszerleál- 
lások. A legutóbbi elemzések tanúsága 
szerint a tervezett állásidő a teljes 
rendszerleállásoknak mintegy 80 szá- 
zalékát teszi ki. A Sun Microsystems 
bebizonyította, hogy mára a tervezett 
állásidő jelentős része kiküszöbölhetővé 
vált a Sun egyedülálló, működés 
közbeni rendszerífrissítési (Live System 
Upgrade) szolgáltatásainak köszön- 
hetően; amelyeknek része a teljes 
eszközredundancia, a hatékony Solaris 
operációs rendszer, a kifinomult erő- 
forrás-használati eljárások. A Sun Fire 
kiszolgálók -— olyan Sun-szolgáltatá- 
sokkal ötvözve, mint például a Sun 
Remote Services (SRS) Net Connect 
szolgáltatás — a működés közbeni rend- 
szerfrissítés alatt is páratlan rendel- 
kezésre állást biztosítanak a Unix-rend- 
szerekben, legkisebbre csökkentve 

a tervezett és az előre nem számolt 
állásidőt egyaránt. Mindez azt jelenti, 
hogy a tulajdonosa magasabb színvo- 
nalon szolgálhatja ki vásárlóit és 
partnereit, valamint magasabb fokú 
rendelkezésre állást biztosíthat fel- 
használóinak. 

2 http:/www.sun.hu 

2 http:/www.sun.com 


Minősítés és biztonság 

Az Oracle és a Red Hat közösen szeret- 
nék megszerezni a Red Hat Linux 
Advanced Server számára a Common 
Criteria FAL2-es szintjének megfelelő 
minősítést. A bejelentés szorosan kap- 
csolódik az Oracle azon szándékához, 
hogy Linux operációs rendszeren futó 
Oracle9i Database Release 2 terméke 
számára formális biztonsági értékelést 


Pe 


nyújtó EAL4-es minősítést szerezzen. 

A két cég a minősítések megszerzésével 
a biztonságos, pontosabban valamilyen 
formális módszerrel, a biztonságot és 
minőséget szem előtt tartó folyamat 
során fejlesztett terméket kereső vállal- 
kozásoknál és szervezeteknél juthat 
előnyhöz. A Red Hat és az Oracle a 
későbbiekben magasabb szintű minősí- 
téseket is meg szeretne szerezni, ezzel 
közös megoldásuk igencsak zártnak 
mondható körbe lép majd be, hiszen 
fontosabb minősítéseket elég kevés 
operációs rendszernek sikerült sze- 
reznie. Törekvésük várhatóan az egész 
Linux-közösség számára fontos elő- 
nyökkel jár majd, hiszen egyrészt ráirá- 
nyítja a figyelmet a biztonság kérdé- 
sére, másrészt az értékeléssel kapcso- 
latos anyagokat nyilvánosan is elér- 


Lf a 


hetővé fogják tenni. 


Irue24 Initiative 

A VIA Technologies Irue24 Initiative 

néven jelentette be új kezdeménye- 

zését, amely a számítógépekbe épített 

hangeszközök - egyébként is lendü- 
letes — fejlő- 


dését hiva- 
sz.ÍTue2d Tart sa tét 


A/LE Örckia Jelenleg az 
asztali szá- 
mítógépekben jellemzően 16-bites, 
44 kHz-es mintavételezésre képes, két- 
csatornás hangkártyák vannak, és túl- 
nyomórészt az alaplapokra épített 
hangeszközök is ilyen jellemzőkkel 
bírnak. A DVD-filmek és Zenei lemezek 
megjelenésével egyre nagyobb lett az 
igény a 24-bites, 96 kHz-es és hatcsa- 
tornás hangra, ezt tükrözi az egy ideje 
már megindult áttérés. A VIA jó érzék- 
kel ismerte fel, hogy nem elég a számí- 
tógépek szokványos építőelemévé 
tenni a csúcsminőségű hangeszközöket, 
hanem szabványos megoldást kell lét- 
rehozni erre a célra, illetve a felhaszná- 
lókkal is meg kell ismertetni a rendel- 
kezésükre bocsátott eszközök tudását 
— a Irue24 Initiative ezt a három terü- 
letet fogja össze egyetlen tervezetté. 
2 http:/www.via.com.tw/en/multimedia 
/true24 a.jsp 
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Harc a himlő ellen 

Az IBM, a United Devices és az Accelrys 
bejelentett egy új gyógyszerek kifejlesz- 
tésére irányuló, világméretű kutatástá- 
mogatási tervezetet, amely jó eséllyel 
veheti fel a harcot a himlővírus ellen. 

A tervezet alapja egy hatalmas számító- 
gépes , grid" lesz, amely világszerte 
több millió számítógép-tulajdonos 
számára teszi lehetővé, hogy gépének 
kihasználatlan erőforrásaival hozzájá- 
ruljon a himlő ellen esetleg bevethető 
gyógyszerek kifejlesztéséhez és vizsgá- 
latához. A himlő ellen jelenleg nincs 
orvosság, a fertőzés egyedül védőol- 
tással előzhető meg. 

A United Devices hálózata korábban 
rákkutatási célokra jött létre, ám amikor 
az internetes közösség az eredetileg 
tervezettnél is jóval több adattal látta el 
a kutatókat, a hatalmas osztott hálózat 
kissé céltalanná vált, illetve irányítói az 
anthrax elleni oltóanyag keresésére 
kezdték használni. 

A megújuló világméretű hálózatba a 
várakozások szerint több mint kétmillió 
számítógép csatlakozik majd, ezzel a 
világ legnagyobb számítógépének telje- 
sítményénél harmincszor nagyobb, 

1,1 teraflop számítási teljesítményt 
nyújtó osztott rendszer jön létre. Az 
érdeklődők egy képernyővédő letölté- 
sével csatlakozhatnak a hálózathoz — 
furcsa és sajnálatos módon az ügyfél- 
program csak Windows operációs 
rendszerek alá érhető el. 

2 http:/www.grid.org 


Ismét elítélték a Microsoftot 

A bíróság arra kötelezte a Microsoftot, 
hogy legújabb termékeibe a továb- 
biakban ne a saját Java virtuális gépét 
(JVM) építse be, hanem a Sun hasonló 
célú megoldását. A Sun egymilliárd 
dollárra perli a Microsoftot, mivel 

az az eredeti, a Sun által fejlesztett 
Java-géppel nem teljesen egyező mű- 
ködésű Java-megvalósításával erősíteni 
kívánta a személyi számítógépek pia- 
cán megszerzett monopóliumát, 
illetve az együttműködési gondokkal 
a felhasználókat a saját .NE1 keret- 
rendszere felé terelte. Az ítélet nyomán 
a Microsoft összeállította Windows XP 
operációs rendszereihez kiadott SP1 
javítócsomagjának SPla jelzésű válto- 
zatát, amelyből nemes egyszerűséggel 
elmaradt a Microsoft JVM, illetve 
hamarosan elkészül az SPtlb jelzésű 
változat is, amelybe már a Sun leg- 
újabb - külön, a Sun oldaláról egyéb- 
ként is beszerezhető - Java virtuális 
gépe kerül. 
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Az IBM felhagy az Itaniumot 

támogató linuxos fejlesztésekkel 

Forrás: hwsw.hu 

Az IBM felhagy az Intel Itaniumot támogató linuxos 
fejlesztéseivel, és a jövőben elsősorban arra összpon- 
tosít, hogy a nyílt forrású operációs rendszert saját 
Power processzoraira igazítsa. Elemzők szerint a lépés 
az Intel és az IBM közötti kiéleződő verseny előjele. 

Ron Favali, az IBM szóvivője az IDG-nek elmondta, hogy 
a vállalat azért döntött a Linux itaniumos fejlesztésének 
leállítása mellett, mert az Intel 64-bites processzora iránt 
igen visszafogott a kereslet. , Jelenleg úgy gondoljuk, 
hogy az Itanium egy tudományos projekthez hasonlít: 
nincs piaca" — tette hozzá. A cégnek azok a fejlesztői, 
akik korábban az Itanium processzorokon futó Linux 
finomhangolásán dolgoztak, immár az IBM Powert támo- 
gató linuxos projekteket segítik. 

Az Intel természetesen nem ért egyet az IBM-mel. 

Mint a processzorgyártó szóvivője elmondta, az Itanium 
iránti kereslet néhány vertikális piacon meghaladta 

a várakozásokat, noha számadatokat nem említett. 
Közlése szerint az Intel és a HP továbbra is teljes erő- 
bedobással dolgozik a Linux Itanium-támogatásának 
továbbfejlesztésén. 


Linuxra épülő mobiltelefonok 

a Motorolától? 

Forrás: hwsw.hu 

A Motorola még az idén piacra dobja első linuxos mobil- 
telefonját, amelyet a jövőben több hasonló készülék kö- 
vet majd. Az amerikai mobiltelefon-gyártó a harmadik ne- 
gyedévben mutatja be A760 készülékét, ami színes kijel- 
zőt, digitális kamerát, videolejátszót, Java alkalmazás- 
futtatási környezetet és Linux operációs rendszert tartal- 
maz. Az A760 először Ázsiában lesz kapható, az Egyesült 
Államokba és Európába csak később érkezik meg. 

"A Motorola A760 csúcskategóriás készülék, de a válla- 
lat feltett célja, hogy alsóbb árkategóriás telefonjait is 
Linux operációs rendszerre építse" — mondta Scott 
Durschlag, a Motorola mobiltelefonokért felelős részle- 
gének üzletfejlesztési igazgatója. Durschlag szerint a 
Linux azért jó választás, mert csökkenti a fejlesztési 
költségeket és a fejlesztésre fordítandó időt, ugyanis az 
operációs rendszer már számos olyan elemet tartalmaz, 
amelyet egyébként a telefon gyártójának kellene megír- 
nia. A Motorola nem fejleszt saját Linux-változatot, 
hanem a kifejezetten beágyazott eszközökbe szánt prog- 
ramokkal foglalkozó MontaVista Software termékét 
használja majd. 


Megkétszereződött a linuxos kiszolgálók 
forgalma az USA-ban 

Forrás: hwsw.hu 

A Gartner Dataguest piackutató vállalat jelentése szerint 
az Egyesült Államokban tavaly a negyedik negyedévben 
közel megkétszereződött a linuxos kiszolgálók forgalma, 
miközben a Unix-kiszolgálók piaca három százalékkal 
visszaesett. 


A Gartner adatai szerint a negyedik negyedévben az 
USA-ban 384,6 millió dollár értékben értékesítettek 
linuxos kiszolgálókat, ami 90 százalékos növekedés a 
megelőző év hasonló időszakának 202,2 millió dolláros 
forgalmához képest. Ezzel szemben a régió összes kiszol- 
gálóértékesítései mindössze öt százalékkal növekedtek. 
A legnagyobb növekedést a piacon az IBM érte el: a 
linuxos kiszolgálók eladásából származó forgalma 159,9 
millió dollárra nőtt a megelőző év megfelelő időszakának 
75,6 millió dollárjáról. A második helyen a HP áll 80,2 
millió dolláros eladással (ami éves szinten 81 százalékos 
növekedésnek felel meg), míg a harmadik helyet a Dell 
szerezte meg 77,1 millió dolláros forgalommal (ami 66 
százalékos éves növekedést jelent). A piacra csupán 
tavaly belépő Sun 1,3 millió dollár értékben értékesített 
linuxos kiszolgálókat a vizsgált időszakban. 


Kiszorít az XP - újabb eljárás 

a Microsoft ellen 

Forrás: terminal.hu 

Az Európai Bizottsághoz újabb eljárási kezdeményezés 
érkezett be a Microsoft ellen. A Computer and 
Communications Industry (CCIA) szövetségébe tömörülő 
Sun Microsystems, AOL Time Warner, Oracle és Nokia 
keresetet nyújtott be a brüsszeli Európai Bizottsághoz a 
Microsoft ellen annak piaci fölényével való visszaélése 
miatt. A vizsgálat megindítására vonatkozó kérelem 
január 31-én érkezett be, melyben a fent említett cégek 
azzal vádolják a redmondi székhelyű óriást, hogy a Win- 
dows XP operációs rendszerébe beépített szolgáltatások 
miatt a versenytársak kiszorulnak az adott területekről. 
Az EU versenypolitikai ügyekért felelős szerve alapos 
vizsgálat alá kívánja vetni a panasztételt, ugyanis a 
brüsszeli Bizottság már azt is szabályellenesnek tartotta, 
hogy a Microsoft Windows 2000 operációs rendszerébe 
beépítette a Media Playert. 


A közbeszerzési pályázat nyertesei 

Az Axelero Internet és a GTS Datanet győzelmével zárult 
le az MKGI által kapcsolt távbeszélő-hálózati internet- 
szolgáltatásra kiírt közbeszerzési eljárás. 

Az Axelero Internet a Miniszterelnökség Közbeszerzési 
és Gazdasági Igazgatósága által kiírt tárgyalásos közbe- 
szerzési eljárás nyomán keretszerződést kötött 1010 
költségvetési intézmény számára nyújtható korlátlan, 
alapszintű kapcsolt vonali internetszolgáltatás 
értékesítésére. 

A keretszerződés megkötését követően az Axelerótól 

a költségvetési intézmények közvetlenül rendelhetnek 
meg, összesen 16 ezer telefonos internethozzáférést, 
amelyek havidíja egyenként bruttó 1499 forint. Az érin- 
tett költségvetési intézmények, így többek között az IHM 
(Informatikai és Hírközlési Minisztérium) is jogosultságot 
szerzett arra, hogy akár belső használatra, akár más 
programjaihoz e keret terhére vásároljon internet- 
szolgáltatást. 


Kelényi Attila (attilacokiskapu.hu) 
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A Linux-felhasználók Magyarországi Egyesületében 
februárban egymást érték az események. 


Az LME évzáró vacsoráját február 14-én este Budán, a 
Mongolian Barbecue étteremben tartotta. Az egyesület 
rendezvényére 61, a Linux és a szabad programok ter- 
jesztése érdekében buzgón tevékenykedő Linux-hívőt 
hívtak meg. A rendkívül jó hangulatú vacsorán sokan 
most találkoztak először egymással, hiszen a számítás- 
technika berkeiben néha évek telnek el, mire személye- 
sen is megismerkedhetünk egy-egy jól ismert becenév 
tulajdonosával. Az est fénypontjaként értékes szakmai 
könyveket vehettek át az elmúlt évben a nyílt forráskódú 
programok népszerűsítésében kiemelkedően segédke- 
zők: Agrai Ferenc, Balázs Tibor, Halász Gábor, Kósa 
Attila, Kósa Lajos, Lajber Zoltán, Nagy Attila, Pásztor 
György, Pozsár Balázs, Sári Gábor, Takács István, Vasas 
Csaba, Zelena Endre és jómagam. 


Küldöttközgyűlés 

Az LME február 15-én délelőtt tartotta éves rendes tiszt- 
újító közgyűlését a budapesti MÁV Bevétel Ellenőrzési 
Igazgatóság (BEIG) épületében. A pontosan 10 órakor 
megkezdődött küldöttválasztó gyűlésen a megjelentek 
kis létszáma miatt 10:15-kor megismételték a szavazást, 
majd körülbelül 10:30-kor megkezdődött küldöttközgyű- 
lés, az elnök (Sári Gábor) beszámolójával. Ezt követte 

az Ellenőrző Bizottság elnökének (Laky Norbert) beszá- 
molója, majd az egyesület titkára, (Balázs Tibor) meg- 
tartotta pénzügyi beszámolóját. Rövid szünet után a köz- 
hasznúsági beszámoló következett, ebből idéznénk né- 
hány érdekesebb részt. 


Konferencia 

A IV. GNU/Linux Szakmai Konferencia az Infoszféra Kft.-vel 
közösen került megrendezésre a Budapesti Best Western 
Grand Hotel Hungaria szállóban. A színvonalas rendezés- 
nek köszönhetően a konferencia nagyon sikeres volt. 

A résztvevők rendkívül hasznosnak tartották az előadá- 
sokat, ahol új gondolatokat, megoldásokat és szakem- 
bereket ismerhettek meg. A konferencia fő támogatója 
az UHU-Linux Kft. volt. Idén az előadókkal karöltve 
Zelena Endre az LME történetének legszínvonalasabb 
konferenciakiadványát készítette el. 


Positive E-Privacy díj 

Az Egyesület eddigi tevékenysége elismeréseként tavaly 
megkapta a nemzetközileg tekintélyesnek számító 
,Positive E-Privacy" díjat. 


Linuxos konferenciasorozat a Mel támogatásával 

A Miniszterelnöki Hivatal támogatásával létrejött sikeres 
Linux Konferenciasorozat tavaly áprilisban ért véget. 

Az egyesület szakemberei hat egésznapos rendezvényen 
próbálták megismertetni az résztvevőket a Linux és 

a Szabad Szoftverek világával. 


CD-írás 
Ez volt tavaly a legsikeresebben működő projekt, ugyan- 
is Balázs Tibor közel hatszáz korongot írt meg. /óth 


www.linuxvilag.hu 


Csaba és Szakszon Mihály közreműködésével szinte 
minden szakmai rendezvényen megjelentek, legutóbb 
a ,Linux a közoktatásban" címűn. Ők ketten egy alka- 
lommal a West End City Center Média Markt üzletében 
is tartottak Linux-bemutatót. 


Sajtó 

Varga Csaba Sándor és jomagam gondoskodtunk 

a Linux népszerűsítéséről. Szervezésünkben és közremű- 
ködésünkkel a Fix.tv-ben beindult egy heti rendszeres- 
séggel sugárzott Linux témájú műsor. A Számítástech- 
nika című folyóiratban Magosányi Árpád cikkét olvas- 
hatták, a Budapesti Nap című napilapban Varga Csaba 
Sándor indított cikksorozatot. Több rádióműsorban is 
felbukkantak az LME képviselői. Legutóbb a , Pénz Piac 
Profit" című műsorban, a Kossuth rádióban, de szerepel- 
tünk a Szabad Világ Számítástechnikai Magazinban, a 
Civil Rádióban, ahol Varga Csaba Sándor, Czakó Krisztián 
és jómagam a szabad programokról beszéltünk. 


Szabadon projekt 

A Szabadon kampány első része 2002. november 1-jétől 
2003. január 31-ig tartott. Kitűzött céljának megfelelően 
felhívta a figyelmet a szabad programok létére és jelen- 
tőségére. A kampány folytatásában együttműködünk 

a hasonló célú civil szervezettekkel (Magyar BSD Egye- 
sület, FSF.hu Alapítvány, FSN Alapítvány). 


Az ftp.fsn.hu háttértár támogatása 

Az egyesület a szabad programok legnagyobb európai 
tárházaként ismert ftp://ftp.fsn.hu/ szolgáltatást kilenc 
120 GB-os merevlemez beszerzésével támogatta. 


Szabad programok a kormányzati szférában 

Az Egyesület nyílt levelet intézett Kovács Kálmán infor- 
matikai és hírközlési miniszterhez a szabad szoftverek 
kormányzati szinten történő felhasználása érdekében. 


Szerencsi Linux-tábor 

Czakó Krisztián szervezésében tavaly ismét nagy sikerű 
Linux-oktató tábor került megrendezésre. Az LME több 
tevékeny tagja és külső szakértők oktatóként vettek 
részt a táborban. 


LIME-private levelezőlista 

A levelezőlista létrehozása a most leköszönő elnökség 
első döntéseinek egyike volt. Az infoolme.linux.hu és az 
elnokseg(olme.linux.hu címek az Ime-privatecolme.linux.hu 
listára lettek átirányítva. A lista sikeresnek bizonyult, 
mert meggyorsította és hatékonyabbá tette az elnökség 
és a tagok kapcsolatát, továbbá az egyesület tevékeny- 
sége is átláthatóbb lett. 


Gibizer Tibor (gibzorolinuxmania.hu) 
Újságíró, immár hét éve a Linux 
elkötelezett híve. Imádja a kutyákat, 

a kerékpározást és az autós csavargást. 
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Linuxvilág 


Linux az oktatásban 


Január végén a Bercsényi Miklós Elelmiszeripari 
SZKI adott otthont a , Linux az oktatásban" című 
rendezvénysorozat első előadássorozatának. 


A történet meseszerű. Egy budapesti iskola lelkes szá- 
mítástechnika tanárai megelégelték az egyik alapítvány 
csúf, bilincses kampányának komor fenyegetését, az 
örökös felhasználásiszerződés-díjak körüli bonyodal- 
makat, a vírusok elleni végeláthatatlan harcot, a megbíz- 
; hatatlan programműködést. 
Bátran szembenéztek az is- 
kola vezetésével, és kimond- 
ták a bűvös szót: , Linux!" 
Az első döbbenetet azon- 
nali józan és meggyőző 
érvek fegyverével győzték 
le, mire az igazgatóság az 
egyetlen keresztülvihető 
választ adta: ,Legyen!" 
Kezdő lépésként a szakma 
hozzáértő mesterei új életet 
leheltek kiszolgálójukba, amelyen a számukra leginkább 
kézenfekvő Mandrake Linux tagadhatatlan előnyeit ak- 
názták ki. Szívük ifjonti heve mint elsöprő áradat terelte 
őket a munkaállomások felé is, hiszen számukra nem 
a programok betanítása az igazi kihívás, sokkal inkább 
a számítástechnika oktatása. Ennek az évnek az elejére 
sikeresen megtisztították a gépparkjukat, és kidobtak 
minden ablakos programot az ablakon. Szinte adta ma- 
gát a kérdés: ha ez ilyen egyszerű, ennyire jó, megbíz- 
ható és az oktatás kitűzött céljainak tökéletesen meg- 
felel, vajon miért nem ezt használja mindenki? A vála- 
szon sem kellett sokáig töprengeni: ,Nem ismerik!" 
Rózsár Gábor, Sallai András (Zalaegerszeg), Wolczán 
György, azaz a három tanár új cél tűzött ki maga elé. 
Belefogtak a , Linux az oktatásban" szakmai konferencia 
szervezésébe. 
Gibizer Tibor (Gibzo): Egy élelmiszeripari iskolában 
mennyire fontos a számítástechnika oktatása? 
Rózsár Gábor: Minden középiskolásnak meg kell 
tanulnia a számítástechnikát, a gazdasági informati- 
kusoknak pedig különösen. 
Gibzo: Miért Mandrake? 
R. G.: Számos Linux-változatot megnéztünk, ténysze- 
rűen elég nehéz lenne megmondani, hogy miért pont 
a Mandrake nyerte meg a tetszésünket. Egyszerűen 
rokonszenves volt. Most már elég sok rejtett apróságát 
kiismertük, így nem áll szándékunkban váltani. E ter- 
jesztésben rögtön tudjuk, hogy mikor hova kell nyúlni, 
ha valami galiba adódna. 
Gibzo: Honnan jött az ötlet, hogy egy ilyen konferenciát 
szervezzetek? 
R. G.: Már a rendszer építésénél sokat beszélgettünk 
arról, hogy milyen jó lenne, ha a többi iskola is megis- 
merné a Linuxban rejlő lehetőségeket. December 
közepén fogtunk hozzá a szervezéshez, tehát csupán 
másfél hónap kellett a megvalósításához. 





Gibzo: Akkor ez egy teljesen önállóan szerveződött 
rendezvény, nem áll mögötte semmilyen cég? 

R. G.: Nem, az iskola teljesen önállóan vállalta fel ezt 

a szerepet. Közben természetesen cégek is bekapcso- 
lódtak támogatóként. Ezúton is köszönjük a Kiskapu 
Kft.-nek, a Linuxvilágnak, a Linux-felhasználók Magyaror- 
szági Egyesületének, a SuSE hazai képviseletének és 
természetesen az UHU-Linux Kft.-nek, hogy megjelené- 
sükkel emelték a rendezvény fényét. Több linuxos fóru- 
mon meghirdettük az eseményt, illetve azt, hogy előadó- 
kat keresünk. Legnagyobb meglepetésünkre többen 
jelentkeztek, mint ahány előadást meg tudtunk tartani. 
Gibzo: Mekkora volt az érdeklődés? Tudjátok, hogy hány 
iskola, mennyi tanár vett részt a konferencián? 

R. G.: A rendelkezésünkre álló termek mérete szabta 
meg a részvevők számát, így hatvan érdeklődőt tudtunk 
csak fogadni, ami sajnos azt jelentette, hogy a későn 
érkező jelentkezéseket már nem tudtuk elfogadni. Egy 
iskolából átlagosan két kolléga jött el, ez nagyjából azt 
jelenti, hogy több mint harminc oktatási intézményből 
érkeztek érdeklődők. Többségük középiskolákból, általá- 
nos iskolákból jött, de a nyíregyházi tanárképző főisko- 
lából is érkeztek hozzánk vendégek. Érdekességként 
megemlíteném, hogy a jelentkezők nagyobb része hölgy 
volt, és talán ennek is köszönhető, hogy rendkívül jó 
hangulatúra sikeredett ez a két nap. 

Gibzo: Terveztek-e folytatást? 

R. G.: Természetesen. Szeretnénk évente 2—3 ilyen ren- 
dezvénnyel megörvendeztetni a kollégákat. Terveinkben 
az is szerepel, hogy a jövőben nemcsak a tájékoztatás, 
eddigi tapasztalataink átadása szerepeljen, de a hétköz- 
napi életben is jól használható ismeretanyagokkal is 
segíteni szeretnénk a munkájukat. Tehát mindenképpen 
szeretnénk oktatni is, ezért próbálunk fokozatokat meg- 
határozni, hogy szintekre tudjuk bontani az előadásokat, 
illetve a gyakorlatokat. Most egy teljesen kezdőknek 
szóló anyaggal jelentkeztünk. 

Gibzo: Talán még korai megkérdezni, de véleményed 
szerint mennyire volt eredményes az elmúlt két nap? 

R. G.: Kicsit visszamennék az időben: amikor a diákokat 
odaültettük a Linux elé, meglehetősen idegenkedtek tőle, 
de az első óra végére megérezték, hogy a számítástech- 
nika nem a Windowsnál kezdődik, és főleg nem ott ér 
véget. Hihetetlenül gyorsan eljutottunk odáig, hogy zök- 
kenőmentesen dolgoztak az új környezetben. 

A kollégáknál ugyanezt tapasztaltuk. Az első bizonytalan 
egérkattintások után csillogó szemekkel fedezték fel a 
lehetőségek szinte végtelen tárházát. Ehhez talán az is 
kellett, hogy azok, akik ide eljöttek, már nyitottak voltak 
az új felé. Ők már kezdik érezni, hogy a Linuxé a jövő. 


Gibizer Tibor (gibzo(€olinuxmania.hu) 
Újságíró, immár hét éve a Linux 
elkötelezett híve. Imádja a kutyákat, 

a kerékpározást és az autós csavargást. 





OpenOffice.org maratoni súgófordító hétvége 





A mai kiélezett helyzetben a GNU/Linux legkomo- 
lyabb segítsége abban, hogy az irodákba is betörjön, 
az OpenOffice.org irodai programcsomag. 


Bár vannak más szövegszerkesztő, táblázatkezelő és 
egyéb feladatok ellátására alkalmas , irodai" programok, 
de vagy fizetős termékekről van szó, vagy messze nin- 
csenek olyan szinten, hogy felvegyék a versenyt például 
a Microsoft Office csomaggal. Az OpenOffice.org egy 
lelkes csapatnak köszönhetően már magyarul szól a fel- 
használókhoz, sőt helyesírás-ellenőrző résszel is büszkél- 
kedhet. Ami eddig hiányzott, az a magyar nyelvű súgó. 
Már közel egy hosszú éve várat magára az angol súgó 
lefordításának nehéz kérdése. Tovább nehezítette a hely- 
zetet, hogy több érdekcsoport különböző célokat szem 
előtt tartva nem egy irányban , húzta a szekeret". 

A civódást most is, mint ahogy tavaly, Somogyi Péter 
oldotta meg, aki magára vállalta egy következő fordító- 
hétvége megszervezését. Szerencsére a mostani hétvége 
szervezésében ismét sokan segítettek. De miért is külön 
kihívás a súgó lefordítása, és meddig jutott a csapat? 
Hogy ezt jobban megértsük, tudnunk kell, milyen 
állapotban volt a fordítás. A programot már lefordították. 
Elméletileg. Azért írom, hogy elméletileg, mert nem tör- 
tént meg a program fordításának komoly és egységes 
lektorálása, az eredmény pedig — valljuk be — sokszor 
kusza, következetlen kezelőfelület. Ráadásul egy olyan 
programról van szó, amelynek a tudása rendkívül szer- 
teágazó. (Már-már szállóigévé vált a fordítók között az 
alábbi mondat: , Nahát, fordítás közben megtanulom 
használni a programot!" .) 

De nem itt volt az egyetlen zavar. A súgó, ami alapján 
dolgoztunk (amit a program mellett megtalálhatunk), 
valójában egy korábbi termékhez készített német nyelvű 
súgó fordítása volt, ebből kifolyólag egyrészt gyakran 
értelmetlen mondatokkal találtuk szembe magunkat, 
másrészt olyan leírásokkal, amik már rég nem voltak 
pontosak. Szerencsére az egyik komoly diót, a súgó xml 
formátumának kezelését /ol/ Jánosék programja levette 
a fordítók válláról, cserébe viszont néha komoly fejtörést 
okozott, ha valamelyik mondat szerkezetét kívántuk 
átalakítani. 

No, ezeken az akadályokon mind átverekedtük magun- 
kat, majd elkezdtük a fordítást, az összegyűltek a Rózsa 
Művelődési házban (a nagybetűs Helyszínen), a többiek 
pedig az ország számos pontjáról, weben keresztül. 
(Pontosabban kezdték, mert én, több sorstársammal 
egyetemben, órákon át a gépem felélesztésével bajlód- 
tam, de ez egy másik történet. . . ) 

Szerencsére a rendkívül nagy falatnak tűnő munkát a 
program kis , rekordokra" osztotta, így a fordítás mene- 
tét folyamatosan követhettük. Sőt volt, aki kifejezetten 
a minél több rekord lefordításának délibábját követve 
döbbenetes sebességgel gyártotta a magyar mondatré- 
szeket. Igaz, akadt, aki csak a harmadik napon vallotta 
be, hogy valójában nincs is angol nyelvű súgója, mi 
több: az OpenOffice.org sincs nála telepítve. Ráadásul 
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volt, aki nem Is Linux vagy Windows alatt dolgozott 
(ugyanis az OpenOffice.org Windows alatt Is fut), hanem 
nagy büszkén egy Macintosh világító almácskája mögé 
bújva kalapálta a billentyűket. 

A csapat hangulata jelentősen javult, amikor a pénteken 
hozott ellátmány részét képező mélyfagyasztott diókré- 
mes palacsinták keménysége szombat délelőttre emberi 
fogyasztáshoz megfelelő szintűre csökkent. 
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Es végül elkészült a magyar súgó Is 


Egy terület viszont komoly vitákat váltott ki, ez pedig a 
szóhasználat. Aki rendszeres olvasója magazinunknak, 
pontosan tudja, hogy én elsősorban a , magyar magyarí- 
tásokat" részesítem előnyben, így gyakran előfordult, 
hogy egy-egy szónál igyekeztem a nem létező fordítói 
szótárat módosítani (mint például a szerintem szörnyű 
kombipanel vagy a tezaurusz esetén). Sőt ami a szabad 
fejlesztésekre jellemző, itt is kialakult: ahány ember, 
annyi vélemény. A jobb gombra előugró helyi menüt 
például több csodanévre is elkeresztelték. Ha valakit 
érdekelnek ezek a szavak (a teljesség igénye nélkül), 
látogasson el a szotar.kiskapu.hu címre, és keressen 

rá az ,(00)" szövegrészre. 

Nagy előny volt viszont, hogy Péter a program teljes for- 
rásával jelen volt, így a fordítás közben a programban talált 
következetlenségeket azonnal ki tudtuk javítani. Amíg az 
ember nem kerül közvetlenül szembe a program felhasz- 
nálói felületével, eszébe sem jut, hogy milyen rendkívül 
nehéz egy párbeszédablakot úgy kitalálni, hogy a gyors- 
billentyűk a helyükön legyenek, a rövid szövegek találóak 
legyenek, és a felhasználó gyorsan kiismerje magát. 
Végül is a munka döntő többsége elkészült, és azzal 
együtt, hogy a fordítás nem teljes, hiszen csupán a 
közös alapmodult és a szövegszerkesztőhöz tartozó részt 
fordítottuk le, a súgó így is eleget nyújt ahhoz, hogy egy 
lelkes titkárnő megismerkedhessen az OpenOffice.org 
szövegszerkesztőjének alapjaival. 


Szy György (Szy.GyorgyOlinuxvilag.hu) 
A Linuxvilág főszerkesztője, 

a Kiskapu Kiadó vezetője. 

Mindenki levelét örömmel várja. 
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Linuxvilág 


Első Magyar PHP Konferencia - beszélgetés a szervezőkkel 


A PHP-nak az utóbbi években bemutatott diadalmenetét 
sokféleképpen lehet mérni a kiszolgálókimutatásokon túl. 
Elég, ha megnézzük, hogy világszerte hány témába vágó, 
vagy egyenesen PHP-ra szakosodott helyi vagy nemzet- 
közi konferenciát rendeznek havonta. Elnézve a PHP 
hivatalos honlapjának rendezvénynaptárát és híreit, 2003 
tavasza a PHP-konferenciák évszaka lesz. Idén először 
hazánkban is lehetőség nyílik a szakma eszmecseréjére 
a magyar PHP-levelezőlista közössége által szervezett 
Első Magyar PHP Konferencián. 


Heilig Szabolcs (Cece): Gábor, ugye nem ez az első 
PHP Konferenciád? 

Hojtsy Gábor (Goba): Valóban, már két nemzetközi 
konferencián is részt vettem Frankfurtban. 

H. Sz.: A legutóbbin nemcsak látogatóként szerepeltél, 
de előadást is tartottál. 
Mégis, hogy lesz valakiből 
egy nemzetközi konferen- 
cián előadó? 

H. G.: 2001-ben sokat for- 
golódtam az előadók körül. 
Az első estén még a nekik 
szánt különvacsorára is 
benéztem, ezért mindenki 
azt gondolta, hogy én is elő- 
adással készültem. Rend- 
szeresen meglepődtek, ami- 
kor kiderült, hogy hallgató- 
ként jöttem el. A PHP fej- 
lesztői közül jó párat isme- 
rek levelezés révén, különö- 
sen a leíráson dolgozókat. 
Ezért annak ellenére, hogy 
magyar résztvevő rajtam 
kívül csak egy akadt (ARábai 
Gyula előadó), sikerült né- 
hány ismerőssel találkozni. 
Ők is azt javasolták, hogy 

a következő évben én is 
készüljek egy előadással. 

H. Sz.: Megfogadtad a tanácsukat? 

H. G.: 2002-ben a konferenciát egy nappal meghosszab- 
bították, így több idő jutott a szakmai programokra. Ezzel 
együtt az előadáshelyekre nagy volt a túljelentkezés. 

A terveket már nyár elején le kellett adni, így bőven jutott 
idő a témák kiválasztására és az átgondolásukra. Mivel 
én a dokumentációs csoportban is dolgozom, kézenfekvő 
volt, hogy a PHP-parancsfájlok leírásáról beszéljek. Két 
előadással kellett jelentkezni, íyy másodikként a számom- 
ra akkor még izgalmas újdonságként jelentkező , rich 
client" témát jelöltem meg. Szerencsére mindkét előadá- 
somat elfogadták. Ezután egy komoly felkészülési időszak 
következett. A forrásanyagok, és háttéranyagok felkuta- 
tása mellett angol nyelvű tévéadásokat néztem, és angol 
nyelvű újságokat olvastam még a tömegközlekedési esz- 
közökön is. Sőt egy főpróbát is rendeztem még itthon, 





egy lelkes kis csoporton próbáltam ki idegen nyelvű 
előadói készségemet. 

H. Sz.: Korábban is volt szó hazai PHP-konferenciáról a 
magyar PHP-levelezőlistán. Az akkori véleménynyilvánt- 
tások szerint még nem tűnt életképes vállalkozásnak egy 
ilyen hazai rendezvény megtartása. . . 

H. G.: Számomra is túl nagy falatnak tűnt ennek a meg- 
szervezése, és nem is voltam biztos benne, hogy egy 
olyan jó kis csapat fog kialakulni, mint amilyen végül is a 
magyar konferencia szervezésére összejött. Pálócz István 
már korábban is ajánlott helyszínt a PHP-levelezőlistán, 
de akkor én ezt az elképzelést nem vettem komolyan. 

H. Sz.: István, te itt lépsz be a képbe? 

Pálócz István: (más néven P/): Majdnem. Idén 
januárban gondoltam egy nagyot, és újra elővettem az 
ötletet. Kijelöltem egy időpontot, amikor márpedig PHP- 
konferencia lesz Magyarországon. Összeütöttem egy 
oldalt, ahol jelentkezni Is lehetett. A ,program" ekkor 
még csak előadás-időpontokat tartalmazott. Megírtam 
az oldal címét a PHP-levelezőlistára, és kíváncsian 
vártam a fogadtatást. Igencsak meglepődtem, mert még 
aznap jelentkezett tíz ember, köztük volt az első előadó 
is, Bártházi András. Nem sokra rá Hojtsy Gábortól is 
kaptam egy levelet, amiben előadónak ajánlkozott. 

Öt előadást terveztem, és mivel egyet magam is bevál- 
laltam, már csak két előadó hiányzott. 

H. G.: Közben néhányan elkezdtünk tippeket adni, mit 
lehetne javítani a programkiíráson. Majd a honlappal 
kapcsolatos kifogások megvitatására került sor. 

P I.: Amin közben folyamatosan jelentkeztek a résztve- 
vők. Egyre többen rágták a fülem, hogy illene valami 
szebb honlapot készíteni. 

H. Sz.: A honlapnak új arca lett. Ezt követte rövidesen 

a harmadik változat Is? 

P I.: Ez már profi grafikus keze munkáját dicséri, és már 
végleges. Bejegyzésre került a phpconf.hu tartomány, 

itt lelhető fel a hivatalos honlap. Összeszerkesztésére 
egy hihetetlen teherbírású honlaphegesztőt is találtunk 
Simon Benjámin személyében. 

H. G.: Millió más dolog is történt, nem csak a honlap 
külalakján és a logón vitáztunk. Első támogatónk, a hely- 
színt biztosító ELTE Radnóti Miklós Gyakorlóiskola mellé 
más támogatók megnyerésén törtük a fejünket. Időköz- 
ben a teljes előadói kör is kialakult. 

P I.: Hála Papp Győző-nek és Szabó Dénes-nek. 

H. Sz.: A helyszín kiválasztása nehéz volt? 

P I.: Egyáltalán nem. Több minden is az iskola mellett 
szólt. Egyrészt kitűnően felszerelt konferenciateremmel 
rendelkezik, ahol mind a hangosítás, mind a számító- 
gépek monitorának kivetítése ingyen megoldható. A leg- 
fontosabb érv talán az, hogy az iskola alapítványának se- 
gítségével képesek vagyunk anyagi támogatást is fogadni. 
H. Sz.: István, továbbra is te maradtál a főszervező? 

P I.: Amolyan koordinátorféleség. Amikor elkezdtem, 
álmomban sem gondoltam volna, hogy ilyen hatalmas 
segítséget kapok. Több listás összejövetel után az a kép 
alakult ki a többiekről, hogy nagyon sok mindent csinál- 
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kell, ezért van a konferencia napján az alakuló ülés. 

H. Sz.: De eleinte mégiscsak teljesen egyedül voltál A Szakosztályról egyelőre annyit, hogy egy már működő, 
a terveiddel? nagy múltú szervezethez próbálunk csatlakozni. Jelenleg 
P I.: A tervekkel igen, de a döntésemet nagymértékben is folynak a tárgyalások. 

segítette az is, hogy a hátam mögött tudhatok olyanba- — H. Sz.: Az összeállt programról alig beszéltünk még. 
rátokat (volt tanítványokat), akikkel egy ilyen rendezvény Mire számíthat, aki ellátogat a rendezvényre? 
könnyedén lebonyolítható. Szerencsére iskolánk igazga- P I.: Az elsődleges célunk 
tója is nagy örömmel fogadta kezdeményezésemet. Arra az volt, hogy felmérjük az 
számítottam, hogy a rendezvény teljes megszervezése igényt egy ilyen rendez- 


nának szívesen, csak nem mernek belekezdeni. 


az én feladatom lesz. Azonban még egy hét sem telt el, vényre, valamit hogy I j 
és azon kaptam magam, hogy egy ütőképes csapat beindítsuk a párbeszédet A PHP-konferencia honlapja 
tagja vagyok. az egyes elszigetelt cso- 5 http://phpconf.hu 


Az ELTE Radnóti Miklós Gyakorlóiskola 
nonlapja 3 http:/Avww.radnoti.hu 

A magyar PHP-levelezőlista 

2 http:/weblabor.hu/vI-phplista 


H. Sz.: Mekkora munka ez? Mennyi időtöket viszi el? portok között. Igyekez- 
P I.: A koordinációs munka javarésze abból áll, hogy tünk minél szélesebb 

a különböző felvetett ötleteket ne hagyjam elsikkadni, és réteget megszólítani az 
találjak valakit, aki felvállalja és véghez viszi azt. Mostan-  előadásainkkal. Lesz be- 


ság az időm nagy részét valóban a rendezvényszervezés 
teszi ki. Általában éjfél körül olvasom az utolsó levelei- 
met, ennek ellenére hajnalban hat körül már a szervezői 
levelezőlistát bújom. A többiek reggel nyolc táján kezde- 
nek bekapcsolódni, és hajnali három-négy óráig vérre 
menő vitákat folytatnak. Mikor és mennyit alszanak, arról 
fogalmam sincs, de azt hiszem ezt jobb, ha nem Is tudom. 
H. Sz.: Most hol tartotok? 

P I.: Eleinte abban reménykedtem, hogy sikerül egy 
ötvenfős rendezvényt összehoznom. Ehhez képest ma 
már kétszáz feletti a jelentkezők száma. 

H. G.: Külföldi támogatónk is akadt már, két angol nyelvű 
PHP-magazin is védőszárnyai alá vonta kezdeményezé- 
sünket. Bővül egyéni támogatóink köre is. Úgy tűnik, 
többen gondolják azt, hogy érdemes ezt a rendezvényt 
megszervezni, mint amennyire kezdetben számítottunk. 
H. Sz.: Gonosz leszek. Rengeteg olyan kezdeményezés- 
ről tudok, amelyek nagy lendülettel indultak, majd a lel- 
kesedés múltán elvesztek a süllyesztőben. Hasonló hely- 
zet tapasztalható példaképp a PHP-kézikönyv fordítócsa- 
patának munkásságával kapcsolatban Is. 

H. G.: A konferenciával együtt céljaink közé tartozik az 
is, hogy a hazai PHP-közösség életét felpezsdítsük, és a 
jó kezdeményezéseknek segítséget nyújtsunk. Ráadásul 
most már a felelősségtudat is hajt minket a fent említett 
nagy számú jelentkező és a támogatók következtében. 
P I.: Felmerült az is, hogy szervezettebb formában lehet- 
ne támogatni akár a leírás fordítását vagy egy tankönyv 
elkészítését is. 

H. Sz.: Láttam, hogy a konferencia programjában a 
"PHP Szakosztály" alapító ülése is szerepel. Mit takar 
ez pontosan? 

P I.: A szervezet létrehozásának célja elsősorban az, 
hogy összefogja azokat a magyarországi kezdeményezé- 
seket, amelyek a PHP nyelvvel kapcsolatosak. Legyen 
az egy leírás fordítása (például: Smarty, PHPDoc, 
PHPGtk stb.), vagy akár egy szabadon hozzáférhető tar- 
talomkezelő, esetleg egy webáruház elkészítése. Renge- 
teg szabad kapacitás van ezen a téren, de mivel nincs 
megfelelő adatcsere, ezek az erők szétforgácsolódnak. 
Egy ilyen szervezet alakításához elsősorban sok ember 
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vezető előadás a PHP 
nyelvről, egy portál felépítésének tervezéséről, elkészí- 
tésének eszközeiről, valamint a PHP oktatásának nehéz- 
ségeiről. Előzetes felméréseink szerint a legnagyobb 
érdeklődés Szabó Dénes Smarty sablonrendszerről szóló 
előadását övezi. 

H. G.: Szeretnénk megtalálni az ifjú tehetségeket, ezért 

a konferenciát egy szabad stílusú, úgynevezett freestyle 
programozási versennyel kötöttük egybe. 

H. Sz.: A kiírásban ez szerepel 5k Compo néven? 

P [.: Igen. A demoscene hagyományain alapuló verseny- 
formát választottuk, azaz minél összetettebb, többet tudó 
alkotásokat várunk, amelyek csupán 5120 bájtot igényel- 
nek. Az ilyen méretkorlátos pályaművek vélhetőleg külső- 
re semmi különöset nem fognak nyújtani. Egyedül a szak- 
ma képviselőinek eshet le az álla, ha abba is belegondol- 
nak, mekkora méretbe van mindez belegyömöszölve. 

H. G.: A verseny győztesei között értékes ajándékok ke- 
rülnek kisorsolásra. Többek között PHP-vel és minden ext- 
rával ellátott tárhely, külföldi PHP-s folyóirat, szakkönyvek. 
P [.: Az ingyenesség ellenére a rendezvény végén tom- 
bola is lesz, ahol hasonló földi jókra számíthat minden 
résztvevő. 

H. Sz.: Mi az az eredmény, amivel már elégedettek 
lennétek? 

P I.: Én akkor lennék elégedett, ha egy igazán jó hangu- 
latú találkozót sikerülne összehozni, ahonnan a legtöbben 
elégedetten távoznának. 

H. G: Örülnék, ha a rendezvényünket zökkenőmentesen 
sikerülne lebonyolítani, amire minden esélyünk megvan. 
Ha látogatóink azt érzik, hogy egy profi rendezvényen 
voltak, és hasznosan töltötték az idejüket, akkor jól vé- 
geztük a feladatunkat. 

H. Sz.: Köszönöm a beszélgetést! 


Heiglig (Cece) Szabolcs (cececphp.net) 
Veszprémben él. Hobbija, kedvenc idő- 
töltése és munkája is a programozás. 
Szabadidejében hajlamos kerékpárra 
pattanni, vagy baráti társaságban 
szerepjátékokkal foglalkozni. 
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Minden egyben 





Az Egyesült Államok Kereskedelmi Minisz- 
tériuma egy olyan új rendszer kidolgozását 
tervezi, amely nagymértékben egyszerűsít- 
hetné a polgárok és a szervezetek közötti 
kapcsolattartást — a használt átviteli csa- 
tornától függetlenül. Az ENUM rendszer- 
ben az előfizetők egyetlen számon keresz- 
tül lennének elérhetők, függetlenül attól, 
hogy telefonon, levélben, üzenőrendszer- 
ben vagy mobilon keresik-e őket. ,,Itt az 
idő, hogy az Egyesült Államok is megmoz- 
duljon" — írta egy levelében a Kereskedel- 
mi Minisztérium. , Biztosítanunk kell, hogy 
az ENUM vásárlóközpontú, biztonságos és 
versenyhelyzetet teremtő módon kerüljön 
megvalósításra." A minisztérium nagy 
hangsúlyt fektet arra, hogy olyan megol- 
dás kerüljön kidolgozásra, amely nem 
csorbítja a polgárok személyes szféráját, 
biztosítja a piaci versenyt és a folyamatos 
fejlesztést is. Az ENUM-ot — amely máris 
13 tagállam támogatását élvezi — a későb- 
biekben nemzetközi szabvánnyá is kíván- 
ják tenni. A rendszer lényege egy a tele- 
fonszámok és internetcímek közötti meg- 
feleltetést biztosító rendszer, melyben az 
azt támogató eszközök a címfordítást ön- 
működően végzik el. Ilyen módon az inter- 
netcím ismeretében az előfizető akár fel is 
hívható, a telefonszámot a webböngésző- 
be beírva pedig önműködően a weblapjára 
navigálhat a vásárló. 

forrás: LinuxFórum 


Iskolák, figyelem! 


A Kiskapu Kiadó saját 
kiadványait 


2099-os 


kedvezménnyel kínálja a magyar 
oktatási intézmények számára. 


A kiadónk gondozásában 
megjelent könyvek katalógusa 
a www.kiskapu.hu/katalogus 

címről tölthető le. 


www.kiskapu.hu 
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PHPRecipeBook 


Ha receptkönyvre van szükséged, akkor ez a te programod. Bevi- 
heted a hozzávalókat, valamint az elkészítési eljárást és mentheted 
őket. Amikor kotyvasztani akarsz valamit, a programmal összeállít- 
tathatod a hozzávalókat tartalmazó bevásárlási listát, amit azután 
kinyomtathatsz. Ha még az is lehetséges volna, hogy a listát a 


emez megsz gen mezeszasszntje Ún u am emma -Ű 
PTE ETET TETETTTSS ÉTTET 


weben keresztül elküldd a helybéli élelmiszerüzletnek, ahonnan 
házhoz szállítanák a szükséges összetevőket, ki sem kellene moz- 
dulnod otthonról. Sajnálatos módon a program nem tartalmaz beé- 
pített recepteket. Előfeltételek: PHP- és SOL-támogatással 
(PostgreSOL vagy MySOL) rendelkező webkiszolgáló, SOL-kiszol- 
gáló és webböngésző. 
2 http:/phprecipebook.sourceforge.net 

David A. Bandel 
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diff -u: Rendszermag-fejlesztési hírek 





Jó hír azoknak, akik arra vártak, hogy megjavítsák a rendszermag- 
ban az LVM1-et. Fél évig tartó működésképtelen állapot és karban- 
tartáshiány után végre eltávolításra került. Joe Thornber adta 
közzé azt a javítófájlt, amely ténylegesen kiveszi a rendszermag- 
ból. Úgy tűnik, mintha ez is a ,szedjük rendbe magunkat a 2.6-os 
változat előtt" mozgalom jegyében történt volna. A levelezőlistán 
szóba került, hogy az LVM1-et az LVM2, a Device Mapper (DM), 
esetleg az EVMS váltaná fel, de egyik sem aratott osztatlan sikert. 
A DM-ből sok szolgáltatás hiányzik, míg az EVMS túl sokkal ren- 
delkezik. Még az is felvetődött, hogy — ahelyett, hogy kivennék — 
meg kellene próbálkozni az LVM1 javításával, de legalábbis keresni 
kellene egy a helyettesítésére alkalmas programot. A jelenlegi ál- 
lás szerint az EVMS az elsődleges jelölt a 2.6-os változat számára, 
de ezt még túl korai lenne kijelenteni. 
A rendszermagfejlesztők ottawai találkozóján (Ottawa Kernel Summit) 
egyetértettek abban, hogy a driverFS nevét megváltoztatják. Mind- 
össze az a gond, hogy senki nem tudja, mi lesz az új név. Patrick 
Mochel a ,kfs" mellett kardoskodik, mások viszont azt mondják, 
hogy túl sok egybetűs és fs típusú név létezik már most is. H. Peter 
Anvin a ,kernelfs" vagy egyszerűen , kernfs" nevet javasolta. 
Pillanatnyilag annyit lehet biztosan tudni, hogy a név változni fog. 
Bevették a Japánban igen népszerű NEC PC-9800-as kiépítés támo- 
gatását, amely nagyjából egyenértékű a nyugati világban elterjedt 
Intel alapú PC-vel. Habár lehetett rajta futtatni az MS-DOS és a 
Microsoft Windows megfelelő változatát, sohasem volt teljesen 
IBM-megfelelő. Miután ez a processzor uralja a japán PC-piac 
40—50 százalékát, e javítófájlok segítségével a Linux rengeteg olyan 
ember számára elérhetővé válik, aki korábban nem juthatott hozzá. 
A Jerf Dike által írt User-Mode Linux most már rendelkezik SMP- 
támogatással. Eddig akárhány processzor volt a rendszerben, az 
UML-folyamatok teljes mértékben egyprocesszorosak voltak. Ez 
egyebek között azt jelentette, hogy az SMP-programok és különö- 
sen magának a rendszermagnak a próbafuttatása nem vezetett 
messzire. Ezzel az új programmal azonban lehetővé válik az olyan 
alkalmazások gyorsabb kipróbálása, amelyek egyébként sok hosz- 
szadalmas újraindítást tennének szükségessé, esetleg a fájlrend- 
szer épségét is veszélyeztetve. 
Az ioct1 felület elavulttá vált. Az új illesztőprogramoknak fájl- 
rendszer alapú csatlakozást kell létrehozniuk a Libfs-sel, ami 
újonnan került be a 2.5-ös fába. Az I/0-vezérlő függvényeket éve- 
ken át ostorozták, amiért nem tarthatók karban, leírás nélküliek 
és egyre kuszább csoportot alkotnak, ám hiába — nem lehetett őket 
megkerülni. Ettől fogva a Linux-fejlesztők egy értelmes felületet 
használhatnak, amely nem okoz több kárt annál, mint amennyi 
hasznot hajt. 
2002. október 31-én befagyasztották a rendszermag bővítését. 
Még túl korai lenne arról nyilatkozni, hogy ennek eredményekép- 
pen viszonylag rövid idő alatt eljutunk-e a 2.6-os változathoz, vagy 
ismét gyors fejlesztések beláthatatlan sorozata kezdődik. Linus 
Torvalds és sokan mások már jó ideje azért küzdenek, hogy a 
rendszermagújítást viszonylag rövid időkeretek közé szorítsák, 
de a megbízható változatok között eltelt idő még mindig években 
mérhető. Ha a 2.6-os változat 2003 áprilisa előtt megjelenik, az 
nagy előrelépés lesz a fejlesztési folyamat fejlődése terén. 

Zack Brown 
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Uj hozzáférési pont 


A WiFi (802.11 vezeték nélküli ethernet) 
hozzáférési pontok (access point, AP a 
hálózatra kapcsolódni képes eszköz) már 
jelen vannak egy ideje, a többségük azon- 
ban igen korlátozott programozási lehető- 
séget biztosít, különösen ahhoz, hogy az 
egyediesítésükre üzletet lehessen alapozni. 
A lapkakészletgyártással foglalkozó Intersil 
(2 http:/Avwwiintersil.com) gondjaiba 
vette ezt a hiányosságot, és PRISM AP 
néven bemutatta új, saját tervezésű, fejlesz- 
tési mintarendszerét. Értékesíthetőségének 
a titka az operációs rendszere, ami beágya- 
zott Linux. A PRISM AP-hoz teljes linuxos 
fejlesztőkörnyezet tartozik, amelyen többek 
között webkiszolgáló, DHCP-kiszolgáló, 
DHCP-ügyfél és SNMP-kiszolgáló futtatható. 
Miután az operációs rendszer Linux, az 
egyes elemeket a saját igényeidnek meg- 
felelően testreszabhatod, illetve tetsző- 
leges terméket fejleszthetsz. A kódot 
flashmemóriába égetheted, és azután 
mindenféle engedélyeztetési költség 
nélkül eladhatod. 
Más szavakkal: nehéz elképzelni bármi 
mást, ami ugyanilyen mértékben progra- 
mozható és értékesíthető volna, vagy lé- 
nyegesen eltérő módon nyújtaná ugyanezt. 
Doc Searis 
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A Linux Journal honlapján 
számtalan gond megoldá- 
sához találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakori 
kérdéseket és az egyéb 
útmutatásokat a 

2 www. linuxjournal.com 
honlapon olvashatjátok el. 
A rovatban közzétett 
válaszokat Linux-szakértők 
kis csapata készítette el. 
További kérdéseiteket 
szívesen fogadják 

(angol nyelven) a 

2 www.linuxjournal.com/ 
[7-issues/techsup.htmi 
címen, ahol csak egy 
kérdőívet kell kitöltenetek, 
de a bts(ossc.com címre 
levelet is írhattok. A levél 
tárgyában szerepeljen 

a ,BIS" kulcsszó. 
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A hónap szakmai tanácsai 


Újraindíthatom a gépet? 

Éppen telepítem a Red Hat Linux 7-et (azt a terjesztést 
használom, amelyet a Red Hat Linux 7 for Dummies 
könyv mellékleteként kaptam). A telepítés látszólag 
elakadt, miután 153 MB-ot telepített a /53 MB-ból, 
Biztonságos-e újraindítani a számítógépemet? 
Marcus, marcusOlesniak.co.uk 


Csak remélni tudom, hogy a számítógéped nem 

vár azóta is a válaszomra. Igen, biztonságos az újra- 
indítás, de mivel nem sikerült a telepítés, nem fogod 
tudni elindítani a Linuxot. Lehet, hogy a telepítő 

CD hibás volt. 

Christopher Wingert, 

cwingert ocwingert-mail.gualcomm.com 


Ha minden lefagyott, akkor nincs más választás, csak 

az újraindítás. Karcmentesek a telepítő CD-k? Biztos 
vagy benne, hogy a merevlemezek jó állapotban vannak? 
Kezdd előlről a telepítést, de ezúttal a lemezrészek 
létrehozásakor válaszd a hibás blokkok ellenőrzését. 

A telepítés emiatt tovább fog tartani, de fény derülhet 

a lemezek bizonyos hibáira. 

Felipe E. Barousse Boué, fbarousseopiensa.com 


A rendszer sem hajlékonylemezről, 

sem CD-ről nem indul 

Van egy Sony Vaio PCG F340-esem, és Slackware-t 
szeretnék telepíteni rá. Egy rossz tanácsra hallgatva 
formáztam a c : meghajtót. Ezután akármit tettem a 
CD-meghajtóba vagy a lemezmeghajtóba, a rendszerindí- 
tásnál érvénytelen rendszerlemez-hibaüzenetet kapok. 
John Krissinger, kriskrosx.2aol.com 


Lépj be a BIOS-ba, és változtasd meg a rendszerindító 
eszközök sorrendjét. A telepítésre használt meghajtó 
— akár a hajlékonylemez, akár a CD-ROM - a merev- 
lemez előtt legyen. 

Christopher Wingert, 

cwingert ocwingert-mail.gualcomm.com 


Nem vagyok biztos benne, hogy a Slackware telepíthető 
a Vaióra; a hordozható gépek támogatása nem egyszerű 
feladat. Ha nem sikerül, próbálkozz inkább a Red Hat, a 
SuSE vagy a Linux-Mandrake terjesztésekkel. Ezeknek 

a telepítője jobb a hordozható gépek alkatrészeinek a 
felismerésében. 

Marc Merlin, marc bts2google.com 


Hordozható gép nVidia videokártyájának 
támogatása 

Kérlek, javasoljatok egy olyan Linux-változatot, amelyik 
képes működni a Dell Inspiron NoteBook számítógéppel. 
A gép UXGA megjelenítővel (1600 x 1200 képpont) és 
nVidia GeForce 2 Go grafikus rendszerrel rendelkezik. 
Sem a Dell, sem a Red Hat nem tud segíteni. Próbáltam 
telepíteni a Caldera régebbi változatait és a Mandrake 
9.0-t, de ezek sem működtek. 

Kamalakar Rao, kmikr(oJuno.com 


ETLLSLET LL 





A gondod arra vezethető vissza, hogy a GeForce-hoz 
való jó illesztőprogramokat az nVidiától kell letölteni, 
mert ezek nem nyílt forrásúak. Telepítsd a neked tetsző 
terjesztést az Xfree 4.1-es vagy 4.2-es változatával. 
Ezután látogasd meg az nVidia honlapját, töltsd le a zárt 
forrású illesztőprogramokat, és kövesd a telepítési 
utasításokat (5 http://www.nvidia.com/view.asp?l0 — 
linux display 1.0-3123]). 

Marc Merlin, marc btsgoogle.com 


A DNS és a DHCP beállítása 

Egy Red Hat 7.3-at futtató számítógépet szeretnék 
iskolám kiszolgálójaként használni. Szükséges-e DNS- 
és DHCP-kiszolgálót beállítani? 

Richard Whiteside, Hendeldevercohotmail.com 


A Red Hat remek eszközökkel rendelkezik ezeknek 

a szolgáltatásoknak a beállításához. Olvasd el az 
Installation Guide-ot, ez elég jól elmagyarázza a 
teendőket (5 http://www.redhat.com/docs/manuals/ 
linux/RHL-7.3-Manual/install-guide). 

Christopher Wingert, 

cwingert ocwingert-mail.gualcomm.com 


Kiváló ötleteket kaphatsz a DNS-HowTo-ban és a 
DHCP-HowTo-ban. Ezek a leírások sok másik mellett 
megtalálhatók a terjesztés CD-jén, vagy az Interneten 
a 5 http://tldp.org webhelyen és tükörkiszolgálóin. 
Mario Bittencourt, mneto(2dargo.com.br 


Hol a nyomtató? 

Szeretném tudni, hogyan kell használni a rendszer- 
nyomtatókat az OpenOffice.org programból. A SuSE 8.0 
Pro csücsül a gépemen, és egy Epson Stylus Photo 
1280 van hozzá beállítva. Az OpenOffice.org telepítése 
után csak a , generic" nyomtatót tudtam elérni. 

Nathan M. Fowler Jr. , nfowler1 obellsouth.net 


Az spadmin programot kellene futtatnod, amit az 
-—/OpenOffice.org1.0.1/program könyvtárban találsz 
meg. Ennek segítségével lehet beállítani a nyomtatókat 
az OpenOffice.org alá. 

Felipe E. Barousse Boué, fbarousse-opiensa.com 


Hol az IP-cím? 

Van egy Linksys útválasztóm. A Red Hat Linux felismeri 
az alaplapra épített ethernetkaput, de sehogy sem 
tudom rávenni a kapcsolódásra. 

Tim Kuder, timCokuderized.com 


Próbáld meg a Red Hat netconfig nevű beállító- 
programját használni. Lehet, hogy be kell állítanod 

a DHCP-t, hogy az IP-címet a DHCP-kiszolgáló adja, 
ahelyett, hogy magadnak állítanál be egyet. Ezután 
pingeld meg az útválasztó címét. Ha ez sikerül, akkor 
a beállítás jó. 

Felipe E. Barousse Boué, fbaroussecopiensa.com 
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Új termékek 


ProStore Backup 
Appliance 

A ProMicro és az Avail Solutions 
összefogásából született meg a 
ProStore Backup Appllance, amely 
adattárolásra, biztonsági mentések 
készítésére és az adatok helyreállítá- 
sára alkalmas. A ProStore készülék 
a ProMicro ProStore NAS-kiszolgá- 
lójából és az Avail Integrity nevű 
adatmentő programjából és önmű- 





ködő szalagkönyvtárából lett össze- 
rakva. A ProStore jellemzői: 360 GB 
tárterület, Intel processzorok, 
10/100-as ethernetkapuk, három PCI 
bővítőhely és legfeljebb hat IDE- 
meghajtó. Mindez egy 2U formájú 
házban kapott helyet. A beépített 
nyolckazettás szalagostár 640 GB 
tömörített adat átvitelére képes 

6 MB/s sebességgel. Minden jellem- 
ző beállítható a felhasználó által. 
Adatok: ProMicro Solutions, 12635 
Danielson Court 4203, Poway, 
California 92064, 

telefon: 866-/76-6427, 

2 http:/Awww.promicro.com; 

Avalil Solutions, 2430 Vineyard 
Avenue, Suite 205, Escondido, 
California 92029, 

telefon: 760-743-7200, 

2 http:/Awvww.availsolutions.com 


ACCPAC Advantage 
Series 5.0 

Az ACCPAC Advantage Serles 
Enterprise Edition 5.0 olyan több- 
rétegű, webalapú vállalatirányítási 
rendszer, amely a teljes könyvelési 
rendszerhez hozzáférést ad a bön- 
gészőn vagy az ACCPAC munkaasz- 
talon keresztül. Az Enterprise Edition 
a következő feladatköröket láthatja 
el: rendszerkezelő, főkönyvi könyve- 
lés, tartozások, követelések, álló- 
eszköz-nyilvántartás, rendelések ke- 
zelése, beszerzés, valamint amerikai 
és kanadai rendszerű bérszámfejtés. 
A főkönyv konszolidálása és a vál- 
lalatközi tranzakciók modul szintén 
rendelkezésre áll. Az Enterprise 
Edition képes több nyelv és több 
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pénznem kezelésére, korlátlan számú 
felhasználót támogat, és együttmű- 
ködik az Oracle, az IBM DB2 és a 
Pervasive adatbázisokkal. 

Adatok: ACCPAC, 6700 Koll Center 
Parkway, Third Floor, Pleasanton, 
California 94566, 

telefon: 925-461-2625, 

2 http:/Awww.accpac.com 


SCO Linux 4.0 

A SCO Group a Caldera márkanév 
használatának abbahagyása óta első 
alkalommal jelent meg új termékkel 
a piacon; bejelentette a SCO Linux 
4.0-t. A SCO Linux 4.0 a UnitedLinux 
1.0-n alapul, és kitüntetett fontos- 
ságú üzleti alkalmazásokhoz tervez- 
ték. Az SCO Linuxhoz programok, 
támogatás és szolgáltatások is jár- 
nak a kis- és középvállalatok számá- 
ra a több mint 16 ezer viszonteladón 
keresztül. A SCO Linux 4.0 négy 
változatban érhető el: Base, Classic, 
Business és Enterprise. Mindegyik- 
hez egyéves támogatás jár. 

Adatok: The SCO Group, 355 South 
520 West, Suite 100, Lindon, Utah 
84042, telefon: 801-/65-4999, 

2 http:/Awww.sco.com 


Freguency Clock: Free 
Media System 
A Freguency Clock: Free Media Sys- 
tem nyílt forrású programrendszer a 
hang- és képfolyamok csatornáinak 
kezelésére. A felhasználók médiafo- 
Ilyamaikat dinamikus csatornákba 
rendszerezhetik, amelyeket webalapú 
médiafolyam-lejátszóval lehet megte- 
kinteni. A Radiogualia által létrehozott 
Free Media System legfontosabb 
szolgáltatásai közé tartozik a testre- 
szabott médiafolyam-lejátszó, amely 
többféle fájltípust ismer, valamint a 
kereshető archívumok és a valós idejű 
statisztikai elemzés. Minden média- 
folyam, többek között a Windows 
Media, a Real és a OuickTime, ugyan- 
azzal a lejátszóval — a Freguency 
Clock Playerrel — játszható le. Ráa- 
dásul a felhasználók a Playert saját 
tervezési szempontjaik alapján 
testreszabhatják, a tervezést nem 
szükséges a lejátszóhoz igazítani. 
Adatok: The Freguency Clock, 
e-mail: radiogualla( Dva.com. au, 
2 http://radiogualla.va.com.au/ 
fregclock/central.htmi 


Zaurus SL-5600 

A Zaurus PDA-családjának legújabb 
tagja az SL-5600, ami egy, az üzleti 
felhasználók számára készített 
vezeték nélküli kapcsolattartásra 
képes tenyérgép. Az 5600-as nagy- 
felbontású, színes OVGA LCD-vel, 
OWERTY billentyűzettel, 64 MB 
védett flashmemóriával, 32 MB 
SDRAM memóriával, kettős bőví- 
tőhellyel (Compact-Flash és 
SD/MMC kártyahelyek), beépített 
hangszóróval és mikrofonnal ren- 
delkezik. A Otopia alapú PDA-ba 
Intel XScale 400 MHz-es procesz- 
szort szereltek, amely a memóriával 
100 MHz-en tart kapcsolatot. Az SL- 
5600 virtuális mobil merevlemezzel 
is rendelkezik, ami a flashmemóriá- 
ban megvédi az adatokat, az alkal- 
mazásokat és az állományokat. 

Az új Zaurus illesztőprogramokat 
tartalmaz a 802.11b vezeték nélküli 
LAN-csatolókhoz, CDPD vezeték 
nélküli modemekhez és 10/100-as 
ethernetkártyákhoz. 

Adatok: Sharp Zaurus, 

telefon: 201-529-9459, 

2 http://www.myzaurus.com 

2 http://www.sharpusa.com 


Cubix BladeStation 

A Cubix Corporation BladeStation 
nevű terméke egy kétprocesszoros 
Pentium 4 Xeon alapú pengekiszol- 
gáló legfeljebb négy PCI-X/PCI kár- 
tyahellyel pengénként. A Blade- 
Station FSB sebessége 533 MHz, 
és minden egyes penge összesen 
négy SCSI-meghajtót támogathat. 
Legfeljebb hét kétprocesszoros 
Xeon penge építhető be egy 6U ma- 
gas keretbe, mindössze 21 hüvelyk 
mélységet felhasználva a keretben. 
Minden penge egy teljes hosszúságú 
64 bites 133/100 MHz-es PCI-X 
bővítőhellyel, legfeljebb 8 GB DDR 
RAM-mal, egy 1 Gb-es ethernet- 
kapuval és két 10/100-as ethernet- 
kapuval rendelkezik. A PowerStation 
tápegységek rendszere hibatűrő 
n--1-es tápellátást biztosít. 

Adatok: Cubix Corporation, 2800 
Lockheed Way, Carson City, Nevada 
89706, telefon: 800-329-0550, 

2 http:/Awww.cubix.com 
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Kevesebb törödéssel 


Ha Linus többet törődött volna azzal, mi történik a rendszermagon kívül, 
a Linux talán sokkal kevésbé hasznos operációs rendszer lenne. 


T avaly októberben több mint száz 
Linux-hívő egy boldog hetet 
töltött a Geek Cruise fedélzetén 
Linus Torvalds társaságában. Noha úgy 
tűnt, hogy több szó esett a családról, 
mint a Linuxról (ha már itt tartunk, ne- 
künk négy hatévesnél fiatalabb gyerme- 
künk van), elégszer hallottam Linust 
technológiai témáról beszélni ahhoz, 
hogy megállapítsam: ennek az ember- 
nek a mantrája három szóból áll: nem 
törődöm vele. 

Linus ezzel a nyilatkozattal kezdte be- 
szédét a hajón: , Én csak a rendszermag- 
gal foglalkozom. A felhasználói szintű 
dolgokkal is törődtem tíz évvel ezelőtt, 
de csak azért, mert nélkülük a rendszer- 
mag nem használható. Nem tudom, mi 
történik a rendszermagon kívül, és nem 
is nagyon érdekel. Csak azzal törődöm, 
ami a rendszermagon belül történik." 
Az, hogy nem törődik mással, nem 
jelenti azt, hogy Linusnak nincs is véle- 
ménye. Mint másoknak, neki is igen 
szerteágazó véleménye van. Velünk el- 
lentétben azonban ő főszereplő, akinek 
a véleménye nagy súllyal esik latba. 
Linus kínosan ügyel arra, hogy kifejtse, 
milyen csekély mértékben törődik bizo- 
nyos dolgokkal, amelyek talán érdeke- 
sek, ám elvonják az ember figyelmét. 
Tökéletes példa erre a politika. Fent 
említett beszédében Linus ezt mondta: 
, zámomra mindenféle politikának csak 
szórakoztatási értéke van. Én nem törő- 
döm vele." S mivel nem törődik vele, 

a Linux hatalmas siker lett. Sőt a sikere 
napról napra növekszik. 

A Linux kezdett meghatározó rendszerré 
válni — mi több, talán ,a" meghatározó 
operációs rendszerré —, mégpedig pusz- 
tán gyakorlati okokból. A Linux olcsó és 
könnyen telepíthető. Olyan egyszerű és 
hasznos, amilyen egy operációs rendszer 
csak lehet. Ez ugyan a Linux-közösség 
számára nem újdonság, de annál inkább 
új azoknak a vezetőknek, akik nem 
szoktak hozzá, hogy az operációs rend- 
szer nem válik elavulttá holmi politikai 
irányváltás következtében. 

Az egyik fórumon felmerült az elavulás 
kérdése. Linus rámutatott, hogy a keres- 
kedelmi programok bizonyos fokig olyan 
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alapmodellre épülnek, ahol az elavulás 
értéknek számít. Például a Windows 98 
megjelenésekor megkérdezték Bill Gates- 
et, hogy mennyire tartja veszélyesnek a 
Mac OS-t. Gates azzal hárította el a kér- 
dést, hogy a Windows 98 valódi ellenfele 
a Windows 95. Nyíltan az volt a cél, hogy 
újabb bevételt nyerjenek ki a teljes ügy- 
félkörükből. Az Apple tervei is nyilván- 
valóan hasonlóak, amikor megjelenteti 
az újabb Mac OS X-es változatokat. A vá- 
sárlók immár két évtizede elkerülhetet- 
lennek tartják ezeket a váltásokat — eddig 
ugyanis nem volt más választásuk. 

A Linuxszal azonban olyan operációs 
rendszert választhatnak az ügyfelek, 
ami nem törekszik arra, hogy elavulttá 
tegye saját magát. Ez a választási lehető- 
ség sokak érdeklődését felkeltette múlt 
nyáron, amikor a Microsoft megemelte 
a Windows felhasználási díját. A kedve- 
zőtlen gazdasági körülmények között a 
drágulás hatására a vezető beosztásúak 
sokkal nagyobb kedvet éreztek a Linux 
kipróbálására. 

A rendszermag szintjén a Linuxnak 
nincsenek kereskedelmi tervei. Pusztán 
az a célja, hogy hasznos legyen. Ha 
emellett még pénzt is lehet vele keresni, 
az jó. Linus és az ő rendszermagja 
egyébként nem törődik vele. Bizonyos 
dolgok menet közben természetesen 
elavulttá válnak. Linus elmondta a 
beszédében, hogy a 2.6-os rendszermag 
eszközrétege teljesen megújul majd. 
Ezek a változások azonban nem azért 
születnek, hogy elavulttá tegyenek bár- 
mit is. Azért történnek, hogy a rendszer- 
mag több szempontból is jobb legyen, 

a lehető leghosszabb ideig. 

A Linux gyakorlatiassága másra is kihat 
a rendszermag által támogatott szám- 
talan lehetőség révén. Ellenpéldaként 
igen nehéz elképzelni, hogy a Microsoft 
vagy az Apple célja az lenne, hogy 
minél több olyan asztali géppel vagy 
felhasználói felülettel együttműködjön, 
amelyet nem saját maga fejlesztett ki. 

A Linux pedig pontosan ezt teszi. Úgy 
biztosítja az együttműködést az ilyen 
asztali gépekkel és kezelőfelületekkel, 
hogy nem törődik velük. 

Dave Sifry így magyarázza ezt a folya- 





matot: , Azáltal, hogy határozottan el- 
különül a rendszermag és a felhasználói 
terület kódja, a rendszermag szilárdabbá 
válik, és erős fejlesztések indulhatnak a 
felhasználói területen. Például a rend- 
szermagon belüli kód visszaszorításával 
a Sambához hasonló kezdeményezések 
nem központosított módon tudtak újat 
alkotni, illetve megbízható, sokoldalú 
programokat készíteni. Nincs szükség a 
Linux-rendszermagot érintő javítófájlra, 
ha meg akarják változtatni a Sambát. 
Ugyanez elmondható a Linux többi 
lényeges alrendszeréről is; ilyen például 
az XFree86, a Gnome, a KDE, a böngé- 
szők, sőt még a glibc is (habár a glibc 
nem olyan jó példa, mint az előzők). 
Amiatt sem kell aggódni, hogy Linus 
esetleg valami rejtett API-t ír, hogy az 
OpenOffice lekörözze az AbiWordöt, 
vagy a Mozilla az Operát, netán a KDE 
a Gnome-ot - bármelyik program legyen 
is Linus kedvence. 

A törődés hiánya a végső pálya, és úgy 
tűnik, ez adja a legjobb alapot más rá 
építő pályáknak. Miközben a Debian 
talán a legkevésbé kereskedelmi érde- 
keltségű Linux-változat, kimagaslóan 
hasznos építőanyagnak bizonyult a 
Lindows, a Xandros és a hasonló rend- 
szerek számára. Ha a Debian ezekkel a 
megvalósításokkal foglalkozott volna, 
valószínűleg sokkal kevésbé lenne 
gyakorlatias. 

Az ,átláthatóság?" is olyan régi jó Linux- 
tulajdonság, amelyre a vezetők mosta- 
nában egyre inkább figyelnek. Vajon 
mikor jön el az az idő, amikor az embe- 
rek ugyanolyan áttekinthetőséget köve- 
telnek meg az általuk használt operációs 
rendszertől, mint a könyvelési rendsze- 
rüktől? Ugyan, ne törődjünk vele. Úgyis 
bekövetkezik majd. 
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Doc Searls (docAssc om) 
a Linux Journal szerkesztője 
és a Cluetrain Manifesto 
társszerzője. 


Ne fejlesszünk Linuxra! 


Jobb, ha akkor választjuk ki a felületet, amikor a program 


ég elmúlt az az idő, amikor 
Ba megengedhettük magunknak, 

hogy egyetlen felületre fejlesz- 
szünk programot. Miért? Mert minden 
felület legalább egy olyan előnyt nyújt, 
amelyet egyetlen másik sem. A Win- 
dows, a Linux/Unix, a Mac OS X, a 
beágyazott Linux és az összes többi 
felület egyedi előnyöket kínál. Ugyanak- 
kor a változó piaci körülmények között 
lehetetlen megjósolni, melyik felület 
kínálja majd a remélt versenyelőnyt. 
A megoldás: nem kell választani. Néző- 
pontunk szerint a programfejlesztők ki- 
használhatják minden egyes felület leg- 
jobb tulajdonságait, amennyiben a több- 
felületes fejlesztés mellett döntenek. 
Ez nemcsak a személyi számítógépekre 
igaz, hanem kiszolgálók, hálózatok, hor- 
dozható eszközök és minden más, kap- 
csolatot biztosító eszköz esetében is. 
Az egyre kevésbé helyhez kötött mun- 
kavégzés a mai osztott hálózatokhoz és 
világméretű szervezetekhez illeszkedő 
hordozható adatokat és hordozható al- 
kalmazásokat követel. 
Ha egy cég talpon akar maradni a piaci 
versenyben, föl kell ismernie, hogy az 
operációs rendszerek sokfélesége meg- 
kerülhetetlen adottság, és válaszul olyan 
alkalmazásokat kell fejlesztenie, amelyek 
a lehető legtöbb felületen gyorsan, tisztán 
és közvetlenül futtathatók. Az így megírt 
alkalmazás kihasználja minden egyes 
felület legjobb tulajdonságait, anélkül, 
hogy minden esetben újra kellene írni 
— ez az eljárás ugyanis korlátozza a fej- 
lesztő céget és óriási időveszteséget 
jelent. A hosszabb távban gondolkodó 
cégek már fölismerték, hogy az egyetlen 
felületre történő fejlesztés kudarcra van 
ítélve, és jobb módszer mellett döntöttek. 


Az egyfelületes fejlesztés drága 

Ha egynél több felületre szeretnénk 
fejleszteni — ilyen módon bővítve 
piacunkat -—, költségeink nyomasztóan 
megnőnek. Minden egyes felülethez 
teljes fejlesztőgárdára lesz szükségünk. 
lalán még ennél is fontosabb, hogy 
minden egyes felülethez teljes karban- 
tartó és terméktámogatási csapatot kell 
alkalmaznunk. Ez minden egyes felület- 
hez a költségek egyenes arányú növeke- 
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dését jelenti, ami hihetetlenül alacsony 
hatékonyságú gazdálkodás. 


Az egyfelületes 

fejlesztés egyirányú utca 

Egy alkalmazást egyetlen felületre fej- 
leszteni a kockázat növelésével egyenlő, 
mivel a felületek között választanunk 
kell még , mielőtt világosan felmérhet- 
nénk a bennük rejlő lehetőségeket. 

Ki tudja, igazunk lesz-e? Ez a döntés 
felemelt és tönkre is tett már program- 
fejlesztő cégeket. A közelmúltban szinte 


Ha egy cég talpon akar maradni a 
piaci versenyben, föl kell ismernie, 


hogy az operációs rendszerek sokfé- 
lesége megkerülhetetlen adottság... 





mindenki azt mondta, hogy a Windows 
(lendületes terjeszkedése és uralkodó 
piaci helyzete okán) a kézenfekvő 
választás — de várjunk csak! A Linux 
komoly versenyben áll a kiszolgálók 
világában és egyre erősebben terjed a 
személyi számítógépek és a beágyazott 
rendszerek világában. Világméretű 
vevő- és profitközpontú cégek döntenek 
a Linux által nyújtott teljesítmény, 
rugalmasság, biztonság és alacsony 
költségek mellett. A korábban kézenfek- 
vőnek tartott felületválasztás többé már 
nem annyira egyértelmű. Meg tudja 
valaki mondani, mikor (vagy hol) követ- 
kezik be ehhez hasonló villámgyors 
átalakulás? Én nem tudom. 


Az egyfelületes fejlesztés nem 

nyitott a hordozható eszközök felé 
Talán a legfontosabb szempont az, hogy 
egyetlen személyi számítógépes vagy ki- 
szolgáló felületre fejlesztve azonnal meg- 
nehezítjük magunknak a hozzáférést a 
világ leggyorsabban bővülő programpia- 
cához, ami nem más, mint a hordozható 
eszközök piaca. Ha például Microsoft 
Windows NI/2000 rendszerre írunk egy 
alkalmazást, eleve kizárunk minden 
költséghatékony módszert, amellyel az 
alkalmazást hordozható eszközökre 
vihetnénk át, mivel a kódot újra kell ír- 
nunk. Figyelembe véve, hogy az alkal- 


már elkészült. 


mazásokat szinte kötelező hordozhatóvá 
tenni, egy alkalmazásnak még az elké- 
szülte előtt a halálos ítéletét jelentheti, 
ha egyetlen személyi számítógépes 

vagy kiszolgáló felületre fejlesztjük. 

A programfejlesztő ipar régóta küzd 
azzal, hogy gazdaságosan alkalmazható 
módszert dolgozzon ki a többfelületes 
fejlesztések számára. Az iparág története 
tele van olyan cégekkel, amelyek meg- 
próbálták, és elbuktak. Miért? 

Az egyik nehézség a teljes körű megva- 
lósítás hiánya volt. Sok eszközkészlet 
bizonyos felületeken a szolgáltatásoknak 
csupán egy részhalmazát nyújtja. 
További gondot okozott az emulációra 
vagy virtuális gépekre való hagyatkozás. 
Mindkettő jelentős és többnyire elfogad- 
hatatlan teljesítménycsökkenéssel jár, 
különösen a hordozható eszközök szá- 
mára, amelyeknek mindennél inkább 
szükségük van a jó futási sebességre. 
Közismert tény, hogy a virtuális gépek 
közti különbségek a megvalósítás során 
különutas megoldásokhoz és teljesít- 
ménynövelő trükkök alkalmazásához 
vezetnek, és ezzel együtt növekedő 
karbantartási igényekhez is. Ez újabb 
költség, azonkívül megkeseríti az ilyen 
munkával megbízott fejlesztők életét. 
Ma azonban már kipróbált módszerek 
léteznek arra, hogy egy alkalmazást 
egyszer írjunk meg, és az azután bárhol 
lefordítható és futtatható legyen. A több- 
felületes fejlesztést végző cégek olyan 
munkakörnyezetet hoznak létre, amely- 
ben a fejlesztést előrevivő újítások végre 
megint a mindennapos munkát jelentik 
- nem pedig a ritka kivételt. 
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Haavard Nord 

A Trolltech ügyvezetője és egyik alapítója. 
Programozói pályafutása kezdetén elfo- 
gadható többfelületes fejlesztőkészletet 
keresett adatbázis-fejlesztéshez. A cég 
termékei megkönnyítik az alkotó munkát, 
mert segítségükkel a fejlesztők az 
alkalmazás kódját egyszer megírva 
közvetlenül futtathatják Windows, 

Linux, Unix, Mac OS X és beágyazott 
Linux felületeken. 
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Az IBM naplózó fájlrendszere 


Naplózó fájlrendszerrel létfontosságú kiszolgálód mindig újra tud indulni. 


Linux rendszermagja folyamatosan új lehetőségekkel 
A bővül, ezek egyike a naplózó fájlrendszerek támoga- 

tása. Az IBM JFS-e a Linuxhoz létező naplózó fájl- 
rendszerek egyike. Ebben a cikkben a JFS működését és jellem- 
zőit tárgyaljuk. Szót ejtünk arról, hogyan kell telepíteni és beál- 
lítani egy Linux-kiszolgálón, valamint milyen tapasztalatokra 
tettünk szert a használata során az Ericsson Research Labnél 
(Montrealban). 
Egy fájlrendszer arra szolgál, hogy a merevlemezeken lévő 
felhasználói adatokat tárolja és kezelje. Biztosítja, hogy az adat, 
amit a lemezre írunk, teljesen megegyezik azzal, amit a lemez- 
ről visszaolvasunk. A fájlok tárolása mellett a fájlrendszer szá- 
mos egyéb adatot is kezel, úgymint a rendelkezésre álló szabad 
terület mértékét, vagy az i csomópontok számát, amelyeket 
a saját céljaira használ fel. A fájlrendszer efféle szerkezeteit 
kiegészítő adatoknak (metadata) szokás hívni, ezekbe a fájl 
tényleges tartalmán kívül minden egyéb beletartozik. A fájllal 
kapcsolatos adatokat, mint a fizikai elhelyezkedését vagy a mé- 
retét is a kiegészítő adatok között tárolják. 





Naplózó fájlrendszerek 

a nem naplózó fájlrendszerek ellenében? 

Egy naplózó fájlrendszer tartalmilag sokkal összefüggőbb, 
ugyanakkor a helyreállítása is jóval egyszerűbb, mint nem 
naplózó társainak. Ennek következtében naplózó fájlrend- 
szerek esetén az újraindításhoz szükséges idő is rövidebb. 

A nem naplózó fájlrendszerek ki vannak téve annak a veszély- 
nek, hogy esetleg megsérülnek, mivel egy-egy logikai fájlmű- 
velet gyakorta több [/D műveleten keresztül kerül elvégzésre, 
így egy váratlan leállás esetleg a folyamat kellős közepén 
szakítja meg a műveletsort. Például egy egyszerű állományba 
történő íráshoz a következő műveletek szükségesek: 


e — lerület lefoglalása a fájlrendszeren. 
e A területek mutatóinak a frissítése. 
e A fájlméret frissítése. 

e Az adat tényleges kiírása. 


Ha a rendszert ezeknek a műveleteknek az elvégzése közben 
szakítjuk meg, akkor a nem naplózó fájlrendszer egy köztes, 
nem összefüggő állapotban marad. Ilyen esetekben ezek a 
fájlrendszerek az fsck nevű eszközre bízzák, hogy feltárja a 
kiegészítő adatokban keletkezett hibákat (például a könyvtár- 
és lemezcímző szerkezeteket), és lehetőség szerint javítsa is 
őket. Azonban az fsck elég időigényes lehet, függően a lemez 
méretétől, a könyvtárak és a bennük található fájlok számától. 
lehát egy nagyobb fájlrendszer esetén a naplózó tulajdonság 
elengedhetetlen, hiszen egy naplózó fájlrendszer kevesebb 
mint egy másodperc alatt képes újraindulni. 


Bemutatkozik a JES 

A JFS-t úgy tervezték, hogy bármilyen üzemzavart követően 
gyorsan képes legyen helyreállni, ezenkívül felkészítették nagy 
lemezrészek és nagyméretű állományok kezelésére, azonban 


22 


Linuxvilág 


ugyanígy megbirkózik nagyszámú könyvtárakkal és fájlokkal is. 
Ahhoz, hogy megfeleljen ezeknek a követelményeknek, a JFS 

a másodperc törtrésze alatt képes helyreállni, úgy, hogy csak 

a kiegészítő adatokban bekövetkező változásokat naplózza. 

A JFS támogatja a 64-bites rendszereket is, akár petabájt 

(2" bájt — 1024 terabájt) méretű fájlokkal és lemezrészekkel. 
Ráadásul a fájlrendszerben található összes szerkezet B-t fákra 
épül. A nagyobb teljesítmény elérése érdekében a fájlrend- 
szerben az összes lehetséges helyen B-- fákat használnak 

a hagyományos lineáris fájlrendszerszerkezetek helyett. 


Fájlrendszerek 
Az állományok úgynevezett fokok sorozatában tárolódnak. 
Foknak nevezzük az egymást követő szomszédos blokkok 
sorozatát, ami a JFS-ben egy egységet jelent. A fokot teljes 
egészében egy csoport belsejében (és ezáltal egyetlen lemez- 
részen) találjuk meg. Nagyméretű fokok azonban több tárte- 
rületi egységre is kiterjedhetnek. Egy fok mérete bármekkora 
lehet 1 és 2" -1 blokk között. Példának okáért a JFS 24-bites 
értéket használ a fok hosszának meghatározására. 4 k-s 
blokkméret esetén a legnagyobb 
fokméret 4 k 2" -1 lehet, ami 
megközelítőleg 64 GB-tal egyen- 
lő. Fontos, hogy ez a határ csak 
egyetlen fokra vonatkozik -— a fájl 
teljes méretét ez egyáltalán nem 
befolyásolja. A fokokat egy B- fa 
alapján tartják nyilván a nagyobb 
teljesítmény érdekében, legyen 
szó akár új fokok hozzáadásáról, 
akár fokok kereséséről stb. 
Általánosságban a JFS elhelyezési 
politikája (allocation policy) a le- 
hető legfolyamatosabb tárterület- 
elrendezést próbálja meg kialakí- 
tani úgy, hogy egy állományhoz 
minél kevesebb fokot használjon 
fel, és ezek a fokok lehetőség 
szerint minél nagyobbak legye- 
nek. Ennek következtében az 

[/D műveletek hatékonysága 
növekszik, ami a teljesítmény 
javulását is magával vonja. 
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A JES története 

Az IBM a Unix fájlrendszerét 
Journaled Filesystem, vagyis 
Naplózó fájlrendszer néven 
mutatta be, amelynek első 
változata az AIX 3.1-gyel jelent 
meg. Ezt a fájlrendszert az 
AIX-en most JFS1-nek hívják. 
Az elmúlt tíz év során ez volt az 
AIX elsődleges fájlrendszere, és 
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vásárlók millióinak a gépein található meg. 1995-ben kezdtek el 
dolgozni azon, hogy a fájlrendszer méretezhető legyen, és 
támogassa a többprocesszoros rendszereket. A másik célkitűzés 
az volt, hogy a fájlrendszer más operációs rendszerekre egy- 
szerűbben átültethető legyen. 

Történelmileg úgy alakult, hogy a JFSI fájlrendszer erősen 
kötődött az AIX memóriakezelőjéhez. Az effajta kialakítás 
jellemző a zárt forrású operációs rendszerekre, illetve azokra 

a fájlrendszerekre, amelyek csak egyféle operációs rendszert 
kívánnak támogatni. 

Az új Journaled Filesystemet, amelyen a Linux-változat is 
alapul, először 1999 áprilisában az OS/2 Warp Server for eBusi- 
ness nevű termékükhöz adták, amelyet sokévnyi tervezés, 
kódolás és kipróbálás előzött meg. Az OS/2 Warp Client nevű 
termék is tartalmazta a fájlrendszert, amit 2000 októberében 
adtak ki. Ezzel párhuzamosan még 1997-ben a JFS fejlesztői 
csapatának néhány tagja visszatért az AIX operációs rendszer 
fejlesztői csoportjába, és elkezdtek dolgozni azon, hogy az új 
JFS az AIX-on is működjön. 2001 májusában Enhanced Journa- 
led Filesystem (]JFS2) néven kiadták a naplózó fájlrendszer 
második változatát az AIX 5L-hez. Mindeközben 1999 decem- 
berében felfedték az OS/2-höz adott JFS forráskódját, és ezzel 
egy időben elkezdődött a JFS átültetése Linuxra. 


Tapasztalatok a nyílt forrású projekttel 

1999 decemberében három naplózó fájlrendszer is fejlesztés 
vagy átültetés alatt volt Linuxra. Az ext2-höz naplózási 
képességeket adtak, és a létrejövő új fájlrendszert ext3-nak 
nevezték. XES fájlrendszerüket az SGI az elkezdte átültetni 
az Irixről. A harmadik fájlrend- 
szer fejlesztését Hans Reiser 
kezdte el, így ennek a neve 
ReiserFS lett. De Linuxon e 
fájlrendszerek egyike sem volt 
teljes egészében működőképes 
1999-ben. Az IBM hitt abban, 
hogy a JFS egy nagyon fejlett 
és markáns fájlrendszer, és 
átültetésével értékesebbé tehet- 
nék a Linuxot. 

Felvették tehát a kapcsolatot 

a vezető linuxos fájlrendszer- 
fejlesztőkkel, és tisztázták hogy 
lehetséges egy újabb naplózó 
fájlrendszer hozzáadása. 

A Linux alapvető szellemisége, 
hogy meg kell adni a választás 
lehetőségét, így ennek fényében elfogadták az újabb naplózó 
fájlrendszer ötletét. 

Az ÍBM 1999 decemberében kezdte el átültetni a fájlrendszert 
Linuxra, és 2000 februárjára már előálltak az első forráskóddal. 
Ez az első változat tartalmazta a bemutató forráskódot, támo- 
gatta a kötetek befűzését és leválasztását, és lehetővé tette az 
ls parancs használatát a JFS-lemezrészen. 





A JES telepítése különálló lemezrészre 

A JFS a 2.5.6-os fejlesztői változat óta része a rendszermagnak, 
de az Alan Cox-féle 2.4.x-ac rendszermagok is tartalmazzák 

a 2002 februárjában kiadott 2.4.18-pre9-ac4 változattól kezdő- 
dően. Alan rendszermagfoltjai a 2.4.x-es sorozathoz a 

2 http:/www.kernel.org címen érhetők el. A 2.4-es rendszer- 
magot külön is letöltheted, és saját magad hozzáadhatod a JFS- 
foltokat. E cikk írásának időpontjában a legújabb rendszermag 
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a 2.4.18-as, a legújabb JFS-változat pedig az 1.0.20-as. A cikk 
további részében ezekkel fogunk dolgozni. A JFS-folt a JES 
honlapjáról tölthető le. Szükséged lesz a JFS segédeszközeire 
(jfsutils-1.0.20.tar.gz) és a fájlrendszerfoltokra 
(jfs-2.4.18-patchés jfs-2.4-1.0.20.tar.gz) is. 
Több Linux-terjesztés már eleve tartalmazza a JFS-t: legújabb 
változataiban a Turbolinux, a Mandrake, a SuSE, a Red Hat és 
a Slackware mind mellékeli a JFS-t. 


A rendszermag felkészítése a JFS-re 

Ha a fentebb felsorolt terjesztések bármelyikét használod, nem 
lesz szükséged a rendszermag foltozására. Csupán annyit kell ten- 
ned, hogy a rendszermagot le kell fordítanod JFS-támogatással. 
Elsőként töltsd le a hivatalos Linux-rendszermagot. Ha a rend- 
szereden már létezik a /usr/src/linux könyvtár, akkor nevezd át, 
így nem fogja felülírni a linux-2.4.18-as forrásfa. Miután letöl- 
tötted a rendszermagot tartalmazó 1linux-2.4.18.tar.gz 
fájlt, mentsd a /usr/src könyvtárba, és csomagold ki. Így létre 
fog jönni egy új /usr/src/linux könyvtár. 

Következő lépésként töltsd le a JFS segédeszközeit és a 2.4.18-as 
rendszermaghoz tartozó foltot. Hozz létre egy könyvtárat a JFS 
forráskódjának /usr/src/jfs51020 néven, és ebbe a könyvtárba 
töltsd le a foltot. Ezt követően lépj be a 2.4.18-as rendszermag 
könyvtárába, és helyezd fel a foltot: 


ax 


ed /úst/eére/lfliíinüx 

patch -pi c /usr/src/jfs1020/jfs-2.4-18- 
"$ögtati 

cp /usr/src/jfs1020/jfs-2.4-1.0.20.tar.gz. 
tar zxví jfs-2.4-1.0.20.tar.gz 


a 


ax 


ax 


A rendszermag beállításakor a make menuconfig vagy make 
config parancsot követően a Filesystems almenüben 
(CONFIG JFS FS-y) engedélyezd a JFS-t. Arra is lehetőséged 
nyílik, hogy a JFS-t különálló bővítménykérnt állítsd be. Ebben 
az esetben elég csak a bővítményeket lefordítanod és feltele- 
pítened: 

5 make modules 66 make modules install 


Máskülönben, ha a JFS-t közvetlenül a rendszermagba akarod 
befordítani, a teljes rendszermagot újra kell fordítanod: 


5 make dep 6 make clean 66 make bziImage 
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Majd fordítsd le és telepítsd a bővítményeket is, ha vannak 


Lf a 


fordítandó bővítményeid: 
5 make modules 66 make modules install 


Végül telepítsd fel az új rendszermagot: 


ax 


cp arch/i386/boot/bzImage /boot/bzImage-jfís 
cp System.map /boot/System.map-jfís 
ln -s /boot/System.map-jfís /boot/System.map 


ax 


ax 


Ne feledd lefuttatni a LILO-t sem! (Ha még sosem fordítottál 
rendszermagot, olvasd el a Kernel-HoOwTo-t, hogy megtudd, 
hogyan kell.) 

Ha a rendszermag fordításával és telepítésével elkészültél, a JFS 
kiegészítéseit is le kell fordítanod és telepítened kell. Másold a 
jÍfsutils-1.0.20.tar.gz fájlt a /usr/src/jfs51020 könyv- 
tárba, majd: 
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0 Kiskapu Kft. Minden jog fenntartva 


0 Kiskapu Kft. Minden jog fenntartva 


ax 


tar zxvÍ  jfsutils-1.0.20.tar.gz 
cd jfsutils-1.0.20 

. /configure 

make 656 make install 


a XX 


ax 


Ha ezzel is megvagy, a következő lépés, hogy egy JFS-lemez- 
részt hozz létre. A következő példában mi egy tartalék lemez- 
részt használunk erre a célra; a következőkben megtudod, 
hogyan kell átköltöztetni egy meglévő lemezrészt JFS-re. 

Ha még van a lemezeden felosztatlan hely, hozz létre egy új 
lemezrészt az fdisk paranccsal. A mi rendszerünk tartalmaz 
egy /dev/hdb3 tartalék lemezrészt, így mi ezt alakítottuk JFS 
fájlrendszerűvé. Miután létrejött az új lemezrész, indítsd újra 
a rendszeredet, hogy megbizonyosodj arról, hogy az új lemez- 
rész képes a JFS fogadására. 

A JFS létrehozásához add ki a következő parancsot: 

5 mkfs.jfs /dev/hdb3 

Miután a fájlrendszer létrejött, be kell fűzni a rendszerbe. 
Ehhez először létre kell hozni egy könyvtárat, ahova a fájlrend- 
szert be lehet fűzni. Legyen ez a könyvtár a /mnt/jfs, majd 
adjuk ki a mount parancsot: 


5 mount -t jfs /dev/hdb3 /mnt/jfís 


Ha a fájlrendszert sikeresen befűzted, készen állsz rá, hogy 
kipróbáld a JFS-t. 
A fájlrendszer lecsatolásához az umount parancsot kell kiadni 


E sea Lp 


az előzőleg létrehozott csatlakozási pontra: 


5 umount /mnt/jís 


Atállás ext2-ról JFS-re 

Az előző szakaszban bemutattuk, hogyan hozzunk létre JFS 
fájlrendszert egy meglévő tartalék lemezrészen. Most azt szem- 
léltetjük, hogyan lehet átalakítani egy tetszőleges fájlrendszert, 
például az ext2-t JFS-re. Megnézzük, miként lehet összeismer- 
tetni a Linuxot egy JFS-lemezrésszel, majd hogyan tehetjük 

ezt a lemezrészt a gyökérfájlrendszerré. 

Milyen elrendezés szükséges egy JFS-gyökérfájlrendszerhez? 
Az átállási folyamathoz egy üres lemezrészre lesz szükségünk. 
Tételezzük fel, hogy a /dev/hda5 tartalmazza a jelenlegi ext2 
gyökérfájlrendszert. Mi a /dev/hda6-ot használjuk JFS- 
gyökérfájlrendszerként. Először az ext2 lemezrész tartalmát 
átmásoljuk a JFS-lemezrészre. Ezt követően, ha nem akarod 
megtartani az ext2-es fájlrendszert, anélkül leformázhatod, 
hogy Linux-rendszeredet elveszítenéd. 

Hogy a JFS-re épülő gyökérfájlrendszert használhasd létre a 


sp ep 


/dev/hda6-on, kövesd az előzőekben leírt utasításokat, hogy 
rendszermagod tartalmazza a JFS-bővítményt. Ahhoz, hogy 
erről az új lemezrészről el lehessen indítani a rendszeredet, 
Linux-telepítésedet egy az egyben át kell másolnod az új 
fájlrendszerre. Ennek legegyszerűbb módja: másolj át minden 


állományt a JFS-lemezrészre. Elsőként fűzd be a fájlrendszert: 
mount -t jfs /dev/hda6 /jfís 


Majd másolj át minden fájlt az ext2 fájlrendszerről a JFS-re: 


ax 


éd. / 
5 cp -a bin etc lib boot dev home usr var 
ert 7 jJjEs 
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A /proc és a /tmp különleges bánásmódot igényel: 


mkdir 
chmod 
mkdir 
chmod 


ax 


/JÉS/pTrOG 
555 /7jís/proc 
/jfs/tmp 
1777 /]Es/tmp 


92 XX 


ax 


Nagyon fontos, hogy a /proc-ot és a /tmp-t a megfelelő jogosult- 
ságokkal hozd létre. Az 1777-es jogosultság azt jelenti, hogy az 
ilyen könyvtárban csak a fájlok és a könyvtárak egyéni tulaj- 
donosai nevezhetik át és törölhetik a fájlokat vagy a könyvtá- 
rak tartalmát, vagy a rendszergazda. Az utolsó lépés magában 
foglalja a /etc/lilo.conf és /etc/fstab fájlok megváltoztatását. 
Elsőként a lilo.conf-ot változtatjuk meg, hogy rendszerünket 

a JES fájlrendszeren lévő rendszermaggal lehessen indítani. 
Figyeld meg, hogy a gyökérfájlrendszer az első bejegyzésben 
különbözik. Mindez azért van így, mert a kötet, amiről a 
rendszerünket el szeretnénk indítani, nem a /dev/hda5/boot 
könyvtárban van, hanem a /dev/hda6/boot könyvtárban: 


image-/boot/vmlinuz-jfs 
label-J3fs-kernel 
read-only 
root-/dev/hda6 


Végül a /etc/fstab fájlon keresztül Linux-rendszerünknek meg 
kell mondanunk, hogy milyen fájlrendszereket fogunk 
használni. Változtassuk meg a következő sort: 


/dev/hda5 7 ext2  defaults 1 1 
hogy így nézzen ki: 
/dev/hda6 Ji jÉs defaults 1 1 


Most újraindíthatod a rendszeredet, és betöltheted a 
jf£s-kernel rendszermagot - így a Linux a JFS gyökérfájl- 
rendszerrel fog felállni. 

Meghibásodást követően a napló önműködően visszajátssza 
a műveleteket. A megszokott fsck üzenetek helyett a JFS 
naplójának üzeneteit fogod látni. A napló visszajátszása elen- 
gedhetetlen, ha a fájlrendszer sérült. 


Az Ericsson Research Lab tapasztalatai a JFS-sel 

Az Ericsson Research Open Systems Labjének egyik feladata 
az, hogy olyan rendszereket tervezzen, hozzon létre és mérjen 
fel, amelyek távközlési alkalmazások alapjául szolgálhatnak. 
Az ilyen távközlési rendszereknek nagyon magas és szigorú 
követelményeknek kell megfelelniük a méretezhetőség, a 
megbízhatóság és a magas rendelkezésre állás terén. Folyama- 
tosan működniük kell, függetlenül bármilyen eszköz- vagy 
programhibától, ugyanakkor lehetővé kell tenniük, hogy hiba 
esetén a rendszerfelügyelők a szolgáltatás megszakítása nélkül 
cserélhessék ki a meghibásodott eszközöket vagy programele- 
meket. Ezért biztosítani kell a lehető legnagyobb megbízha- 
tóságot és a lehető legmagasabb rendelkezésre állást, amire 
gyakran csak mint öt-kilences megbízhatósági szintre hivat- 
koznak (azaz: 99,99999-ban üzemképes). 

Az ehhez hasonló távközlési programokat úgy fejlesztették ki, 
hogy a írissítést a szolgáltatás szüneteltetése nélkül lehetővé 
tegyék, emellett hibatűrők és tartalék hálózati kapcsolatokkal 
rendelkeznek, hogy szerencsétlenségek - akár földrengés — 
esetén is megfelelően működjenek. 

Bár a rendszer tervezésekor mindent elkövetnek, hogy min- 
denféle esetlegesen felmerülő hibát megakadályozzanak, 


mindig van egy picinyke esély, hogy egy processzor (vagy egy 
kiszolgáló csomópont) téveszteni fog. Ebben a nagyon kivételes 
esetben képesnek kell lennünk újraindítani és újra üzemképes 
állapotba hozni ezt a részt, hogy amilyen gyorsan csak lehet, 

a lehető legkisebb kieséssel újra ki tudja szolgálni a kéréseket. 
A naplózó fájlrendszerek iránti érdeklődésünk a távközlési 
Linux-rendszereken annak köszönhető, hogy az ilyen fájlrend- 
szerek képesek a gyors újraindulásra. Egy esetleges meghibá- 
sodás esetén a naplózó fájlrendszer a fájlrendszert a lehető 
leggyorsabban képes újra összefüggővé tenni, ezáltal jóval 
megbízhatóbb, mint az egyéb fájlrendszertípusok. 

Az ÍBM JFS-sel való kísérletezést valamikor 2000 elején kezdtük 
el. A JFS-csapat nagyon segítőkész volt, és képviselőjük, Steve 
Labs 2001 januárjában meglátogatta a laboratóriumunkat. 
Azóta szorosan követjük a JFS fejlesztését és kiszolgálóink min- 
dig a legfrissebb változatot futtatják. 

Első JFS-telepítéseinknek egy 1U lemeztömb adott otthont, 
melyben egy 500 MHz-es Celeron processzor dolgozott, 256 
MB RAM-mal és 20 GB-os IDE-lemezekkel. Ezek az eszközök 
biztosították számunkra a munkakörnyezetet, amelyben a JFS-t 
kipróbálhattuk, és alkalmazásaink használata során 
tapasztalatokra tehettünk szert. Amióta a JFS 1.0.0-s változata 
2001 júniusában megjelent, úgy döntöttünk, hogy kísérleti 
Linux-rendszerünkre is JFS-t telepítünk (2. kép). 
Linux-rendszereink úgy lettek megtervezve, hogy rövidtranz- 
akció-alapú kéréseket szolgáljanak ki. A JFS biztosít egy napló- 
alapú, bájtszintű fájlrendszert, amellyel elsősorban a tranz- 
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akció-középpontú rendszereket célozzák meg, ez illik a mi 
rendszerünkre is a legjobban. 

Távközlési szempontból a JFS előnye, hogy a fájlrendszert 
nagyon összefüggő szerkezeti egységekben tárolja, könnyen 
helyreállítható, és sokkal gyorsabban képes újraindulni, mint 
nem naplózó társai, a hagyományos Unix-fájlrendszerek. 

A rendszer meghibásodása esetén a többi fájlrendszer rend- 
szerint könnyen megsérül. Az ilyen fájlrendszerek egy helyre- 
állító eszközt tesznek szükségessé, mint amilyen az fsck is. 
Az ilyen helyreállító eszközök végigfésülik a fájlrendszer kiegé- 
szítő adatait, és kijavítanak minden hibát, amire a fájlrendszer 
szerkezetében rábukkannak. Ez a művelet azonban rendkívül 
időpazarló tevékenység, amelynek során könnyedén hiba 
léphet fel, és a legszerencsétlenebb esetben rossz helyre vagy 
rosszul állít vissza adatokat. A távközlési rendszerek nem 
engedhetnek meg maguknak olyan műveleteket, amelyek 
tovább növelik a kiesést. 

A JFS-sel meghibásodás esetén a fájlrendszer egy összefüggő 
állapotba kerül vissza, úgy, hogy a fájlrendszer a megfelelő 
tranzakciókhoz megismétli a naplóban rögzült műveleteket. 
Az ilyen naplóalapú rendszereknél a helyreállításhoz szükséges 
idő lényegesen kevesebb, mivel a helyreállítás során nem kell 
az összes bejegyzést átfésülni, hanem csakis azokat, amelyek 
a leállás során működőek voltak. 


Összegzés 

A JFS-nek kulcsszerepe van, mivel egy esetleges rendszerleál- 
lást követően nagyon gyors fájlrendszer-újraindítást eredmé- 
nyez. A JFS-csapat elsődleges és legfontosabb célja, hogy meg- 
bízható, magas rendelkezésre állású fájlrendszert hozzon létre. 
A JFS-csapatnak nagy szerepe van a JFS Linuxra való átülteté- 
sében. A teljesítmény szempontjából sok különféle mérést 
alapul véve a JFS megint csak győztesen kerül ki. A JES Project 
honlapjáról a developerWorksön további érdekességeket 
tudhatsz meg. 


Köszönetnyilvánítás 

Köszönet az Ericsson Research Open Systems Lab csapatának, 
hogy támogatták a Linuxszal és nyílt forrású rendszerekkel 
folytatott munkánkat. 


A cikkhez kapcsolódó anyagok a 45. CD Magazin/]JES könyv- 
tárában találhatóak. 


Cinax dociinal 2003." janúát 108. Szám 


Steve Best (sbesteous.imb.com) 
Austinban (lexas), az IBM Linux lechnology Centerben dolgozik. 
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Linux új méretarányban: az SGI Altix 3000 rendszer 


64 processzorával és az 512 GB memóriájával az SGI 
igényt tart a világ legerősebb Linux-rendszerének a címére. 


z SGI nemrégiben lépett színre új 64-bites, 64 procesz- 
AA szoros, Intel Itanium 2 lapkákon alapuló Linux rend- 

szerével — ami jelentős lépés mind a cég, mind a Linux 
számára. Ez a rendszer új távlatokat nyit, hiszen az összetett és 
igényes magas teljesítményigényű számításokon (High-Perfor- 
mance Computing, azaz HPC) dolgozó tudósok olyan körülmé- 
nyek között használhatnak és telepíthetnek Linuxot, amelyre 
ez idáig még nem volt példa. A HPC környezetek mindig az 
operációs rendszerek végső határait feszegetik, folyton több 
központi egységet, magasabb KB sávszélességet és gyorsabb, 
hatékonyabb párhuzamos programozási támogatást követelve. 
A rendszer fejlesztésének korai szakaszában az SGI úgy 
döntött, hogy a Linuxot választja új felületének kizárólagos 
operációs rendszeréül, mivel bizonyítottan erős és megfelelő 
operációs rendszer az SGI által megcélzott számítási környeze- 
tekhez. A SGI NUMAflex globálisosztottmemória-rendszerével, 
az Intel Itanium 2 központi egységekkel és a Linux haszná- 
latával már jóval a rendszer tényleges bemutatása előtt meg- 
döntött minden rekordot. 
Az új rendszer, amely az SGI Altix 3000 nevet kapta, legfeljebb 
64 processzorral és 512 GB memóriával rendelkezik. A következő 
változatok azonban már 512 processzort és 4 IB-ot kínálnak majd. 
Ebben a cikkben az új SGI-rendszer mögött rejtőző alkatrészter- 
vezést fedezzük fel, leírjuk, hogy milyen programfejlesztéseket 
kellett végrehajtani, hogy az új rendszert kivihessük a piacra, 
illetve megmutatjuk, milyen készségesen méretezhető és alkal- 
mazható a Linux a legigényesebb HPC-környezetekben is. 


Alkatrészháttér és rendszerfelépítés 

Az SGI Altix 3000 rendszer Intel Ítanium 2 processzorokat 
használ, és az SGI NUMAflex memóriakezelési szerkezetén 
alapul, ami a nem egységes memóriaelérés- (Non-Uniform 
Memory Access — NUMA) szerkezet SGI-féle megvalósítása. 

A NUMAflex 1996-ban mutatkozott be, és azóta használják a 
cég megújított SGI Origin kiszolgálócsaládjában, illetve a MIPS 
központi egységen alapuló szuperszámítógépeiben, valamint 
az Irix 64-bites operációs rendszerben. A NUMAftflex-tervezés 
lehetővé teszi, hogy a processzort, memóriát, K/B rendszert, a 
kapcsolatokat, a grafikát és a tárakat moduláris alkotórészekbe, 
úgynevezett téglákba csomagoljuk. Ezek a téglák hihetetlen 
rugalmassággal kombinálhatók és állíthatók be, hogy az 
eredmény a vásárló erőforrás- és munkaterhelési igényeinek 
mind jobban megfelelhessen. Ezt a harmadik nemzedékbeli 
tervezést módosítva az SGI ilyen téglák haszlatával képes volt 
felépíteni az SGI Altix 3000 rendszert a Ki/Bemenet (IX- és PX- 
téglák), a tárhely (D-téglák) és a kapcsolatok (útválasztó tég- 
lák/R-téglák) részekhez. Az új rendszer fő eltérése a processzor- 
tégla (C-tégla), amely az Itanium 2 processzorokat tartalmazza. 
Az SGI Altrix 3000 rendszerében alkalmazott téglatípusokat az 
1. ábra mutatja be. A 2. ábra azt írja le, miként lehet ezekből a 
téglákból két keretet összeállítani, létrehozva egy egységes 
rendszerlenyomatú 64 processzoros rendszert (single-system- 
image 64-processor system). 
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1. ábra NUMATflex-téglatípusok 


A Linux felkészítése az új alkatrészkészletre 

Egy olyan jól megtervezett és kiegyensúlyozott alkatrészrend- 
szeren, mint a NUMAtílex, az operációs rendszernek kell gon- 
doskodnia arról, hogy a felhasználók és az alkalmazások az 
alkatrészeket teljes mértékben kihasználhassák anélkül, hogy 
közben a pocsékoló erőforrás-kezelés vagy a valahol egy szűk 
keresztmetszet hátráltatná őket. Hogy a nagy NUMA- 
rendszeren kiegyensúlyozott alkatrészerőforrás-kezelő 
rendszert tudjunk létrehozni, a rendszermagfejlesztést jóval 
azelőtt meg kellett kezdenünk, hogy az első Itanium 2 lapkák és 
alkatrészprototípus-rendszerek megérkeztek volna. Jelen 
esetben felhasználtuk az Itanium lapkák első nemzedékét, hogy 
a keresett HPC-környezethez szükséges processzorméretezést, 
a K/B teljesítménynövelést és az egyéb változtatásokat a Linux 
rendszeren elvégezhessük. 

A program előkészítésének első lépése, még mielőtt az alkat- 
rész-prototípusok megérkeztek volna, annak a lehető legpon- 





2. ábra Két lehetséges NUMAflex-összeállítás 


tosabb megállapítása volt, hogy milyen alacsony változásokat 
kell a rendszermag alacsony szintű (regiszterek és alkatrészek 
szintjén) kódjában eszközölni, hogy elinduljon és megbízha- 
tóan fusson. és futtatásához. Azok a rendszerkészítők, akik 
saját, különösen fejlett rendszerekhez szánt ASIC tervezésébe 
fognak, általában szimulációs programokat és eszközöket hasz- 
nálnak alkatrészterveik kipróbálásához. Mielőtt még a vasat 
megkaptuk volna, kifejlesztettünk és széles körben használ- 
tunk szimulátorokat a rendszerprogramokhoz (firmware) és 

a rendszermag fejlesztéséhez egyaránt, hogy segítségükkel 
elkészíthessük a rendszerszintű programokat. 

Amikor az első nemzedékbeli ÍItanium processzorokkal ellátott 
eredeti alkatrész-prototípus megérkezett, eljött az üzembe he- 
lyezés ideje. Az egyik legfontosabb mérföldkő a rendszer első 
bekapcsolása, a processzor újraindítása (reset), majd az első 
utasítások PROM-ból történő kiemelése és végrehajtása volt. 
Az indítás után az alkatrészfejlesztési laborban hosszú órákon 
és hétvégeken keresztül tartott az igazi móka. Ez volt az a 
labor, ahol az alkatrészeket, a kipróbálást végző és a felületet 
tervező mérnökök szorosan együttműködtek egymással a 
rendszer hibaellenőrzésében, keresztülsegítve a processzort 
számos lényeges állomáson: eljutottak az PROM-tól az indítási 
promptig, a Linux-rendszermag futtatásától a felállásig, továb- 
bá túljutottak a gyökérfájlrendszer olvasásán és befűzésén, az 
egyfelhasználós mód elérésén, majd a többfelhasználós módba 
lépésen, végül a hálózati csatlakozáson. Ezt követően ugyanezt 
több processzorral és több csomóponttal - többnyire párhu- 
zamosan haladva - néhány, más állomásokon dolgozó felhozó 
csapattal is végigcsináltuk, akik szorosan követték a vezető- 
csapat fejlődését. 

Miután az első nemzedékbeli Itanium processzoros prototípus- 
rendszereken sikerült a Linuxot futásra bírni, a programmér- 
nökök nekiláthattak a munkának, immár tudva, hogy a Linux 
fut, és ami talán még fontosabb: jól méretezhető a NUMA- 
rendszereken. Számos házon belüli, első nemzedékbeli Itanium 
alapú rendszert építettünk fel és használtunk, így meggyőződ- 
hettünk róla, hogy a Linux a nagyrendszereken tényleg jól 
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egy 32-processzoros Itanium alapú rendszert. 
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T. kép Az alkatrészeket tervező mérnök, a PROM-ot megalkotó mérnök 
és a rendszermérnök megvitatnak egy hibát 
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3. kép Az ltanium 2 alapú C-tégla első indulása 


Ezek az első nemzedékbeli Itanium alapú rendszerek kulcsfon- 
tosságúak voltak, mert a segítségükkel tudtuk a Linuxot az igé- 
nyes HPC-követelményeknek megfelelőre formálni. Így már 
jóval azelőtt, hogy az Intelnél az első Itanium 2 processzorok 
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Feladatmegoldások valós környezetben 


Következő példáinkban három tudományos 
HPC-alkalmazás teljesítményét mutatjuk be 
Linuxot futtató SGI Altix 3000 rendszeren. 
Három példarendszerünk a bioinformati- 
kához szánt FASTA, a számítógépes kémiai 
feladatokra tervezett Gaussian és a folya- 
dékdinamikai modellezésre használt STAR- 
CD lesz. Az összes próbát az SGI vezette. 


FASTA bioinformatikai példa 

Bár a biokémia és a számítógépes biológia 
már a 1980-as évek közepétől kezdve 
létezik, a bioinformatika viszonylag fiatal 
tudományága, amelyet az adatigényes 
élettudományok és a laboratóriumauto- 
matizálási technológiák közeledése, illetve 
a hatalmas adatmennyiséget gyorsan szer- 
vező, feldolgozó és szétosztó számítógépes 
adatbázisok és algoritmusok megjelenése 
tett megvalósíthatóvá. A bioinformatika 
segítségével az új gyógyszerek hamarabb 
kerülhetnek piacra, megakadályozhatjuk 

a genetikai fertőzéseket, fertőzés- vagy szá- 
razságtűrő kukoricát hozhatunk létre, meg- 
hosszabbíthatjuk az ételek szavatosságát, 
választási lehetőségünk lesz az olajkérdésre 
vonatkozóan, és létrehozhatjuk a jövő éte- 
leit, amelyek segítenek majd a koleszterin- 
szint szabályozásában és megelőzik a rákot. 
A gyorsan növekvő nyilvánosan elérhető 
biológiai adatok mennyisége miatt a szek- 
vencia-adatbáziskeresés a bioinformatika 
egyik legkényesebb területe. A Smith-Wa- 
terman-féle (ZT. E Smith és M. S. Waterman, 
1981, Journal of Molecular Biology 147: 
195—197) klasszikus keresési módszerek 
nyújtják a biológiai adatbázisok leghatéko- 
nyabb módszerét a szekvenciahasonlósá- 
gok kereséséhez. Csakhogy a Smith-Water- 
man-módszer elég számításigényes, így az 
eljárás hatékony felhasználásához különö- 
sen fontos a párhuzamosítás. Az egyik ilyen 
párhuzamosított Smith-Waterman-megol- 
dás a FASTA bioinformatikai csomag (W. R. 
Pearson, 1991, Genomics 11: 635—-650). 

A Smith-Waterman-algoritmus FASTA 

3.4 változatát (ssearch34 t) -— ami egyéb- 
ként a Virginiai Egyetem lapján 
(alpha10.bioch.virginia.edu/fasta) fellel- 
hető — használtuk 64 processzoros SGI 
Altix 3000 rendszerünk párhuzamos 
teljesítményének a mérésére. 

A Smith-Watermant 

P-szálakkal (Pthread) párhuzamosítottuk, 
az SGI ChemBio Applications csapat pedig 
a magalgoritmust tovább finomhangolta, 
hogy az még jobban kihasználhassa az 
SGI Altix 3000 rendszer képességeit. 
Végeredményül a Smith-Waterman-algo- 
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l. ábra 
A FASTA teljesítménye csaknem lineáris 


ritmus közel eszményi méretezhetőséget 
mutatott (a tökéletes méretezhetőséget 
a pontozott vonal jelzi), 64 processzoron 
futtatva közelítőleg 59x-es sebességnö- 
vekedést értünk el. 


Gaussian számítógépes kémiai példa 
Nemzeti kutatólaboratóriumok, egyetemek, 
gyógyszeripari és biotechnológiai cégek és 
vegyészeti vállalatok is használnak a 
Gaussian Inc. (3 http://wvww.gaussian.com) 
Gaussian 98 rendszeréhez hasonló számító- 
gépes kémiai alkalmazásokat a mole- 

kuláris energiák, tulajdonságok és reakciók 
kutatásában, elektronikus szerkezetekkel igen 
nagy molekularendszereket modellezve. 
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II. ábra 
Gausslan 98 eredmények 


A II. ábrán a Gaussian 98 méretezhetősé- 
gére vonatkozó eredményeket figyelhetjük 
meg, amelyeket a Gaussian OA-suite nevű, 
széles körben alkalmazott teszttel készítet- 
tünk, egy korai SGI Altix 3000 prototípus- 
rendszeren az inkább Itanium, semmint 
Itanium 2 processzorokhoz szánt Intel-for- 
dító korai változatát használva. Az itt lát- 
ható eset a Valynomycin molekulának 
(C54H90N6013) a sűrűségalapú elmélet 
(Density Functional Theory) szerinti erő- 
számításait mutatja be. A grafikonon 
megfigyelhetjük a tesztben kialakult párhu- 
zamos sebességnövekedést. Az eltelt időt 
másodpercben adtuk meg. Az eszközök 





és a rendszer korai változatai ellenére 

a számításhoz szükséges idő az SGI Altix 
3000 rendszer húsz processzorának fel- 
használásával körülbelül 4,5 óráról mind- 
össze 25 percre csökkent. 

STAR-CD számítógépes 
folyadékdinamikai példa 

A számítógépes folyadékdinamikát 
(Computational Fluid Dynamics, azaz CFD) 
számos hagyományos ipari ágazat is hasz- 
nálja, többek közt az autóipar, az űrkutatás 
és az energiatermelési ágazat. A Computa- 
tional Dynamics Limited (5 http://www.cd- 
adapco.com) STAR-CD programja a folya- 
dékáramlás témakörében a CFD-módszer 
egyik vezéralakja. A CFD-felhasználót 
végigsegíti a kezdeti alapvető tervezéstől 
kezdve a valós értékekkel bíró tanulmá- 
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III. ábra 
STAR-CD eredmények Linux, 
HP-UX és AIX összehasonlításban 


nyokon át a hatékonnyá tételig, felajánlva 
fejlett fizikai modelljét, illetve azt a 
képességét, hogy strukturálatlan hálókkal 
összetett geometriai formákat is kezelni 
képes. A STAR-CD minden vezető Unix- 

és NT-felületen üzemel. Párhuzamosított 
kiszolgálókon, erősen párhuzamosított 
rendszereken és munkaállomások telepein 
fut. A STAR-HPC az MPI könyvtárat hasz- 
nálja a magas szintű méretezhetőség eléré- 
séhez. SGI Altix 3000 rendszeren a STAR- 
CD előzetes kiadását és az autó áramlástani 
modelljéhez szánt , Model A Class Dataset" 
felhasználását futtatva az előzetes teljesít- 
ménypróbák alapján a Linux ismét bizonyí- 
totta kitűnő processzorméretezhetőségét 

— egészen 64 processzorig. A 2002 novem- 
berében a 3 http://www.cd-adapco.com/ 
support/bench/aclass.htm lapon közölt ada- 
tok szerint a Linux jobban méretezhető, 
mint két másik kereskedelmi rendszer: 

a Hewlett Packard HP-UX és az IBM AIX 
rendszere. 

A III. ábrán a STAR-CD összehasonlító 
eredményett láthatjuk a Linux, a HP-UX és 
az AIX rendszerek között. 
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3. ábra Fájlrendszerteljesítmény-összehasonlítás: AIM/ 
többfelhasználós rendszermag terhelése, 2.4.18-as rendszermag 
28 P Itanium mintapéldánnyal, 14GB, 120 lemez; különböző fájlrendszerek, 
az SGI álltal kiegészített és finomhangolt rendszermaggal 
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4. ábra Linux XSCSI teljesíménypélda: a 2.4.16-os rendszermaggal; 
120 folyamat 120 merevlemezről olvas 
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5. ábra Processzorskálázási példa az AIM7-el: AIM7 többfelhasználós 
rendszermag terhelése, 2.4.16-os rendszermag; SGI-kiegészítések és 
finomhangolás a rendszermagban 


elérhetővé váltak volna, már fejleszteni lehetett és ki lehetett 
próbálni a méretezést, a K/B teljesítményt és az egyéb 
változtatásokat. 

Miközben az SGI[-programmérnökök a teljesítményen, a 
méretezésen és más feladatokon dolgoztak az első nemzedék- 
beli Itanium processzorokkal felszerelt prototípusokon, az 
alkatrészeket tervező mérnökökből és felületet késztő mérnö- 
kökből álló másik csapat felkészítette az indításra a következő 
nemzedékbeli Ítanium 2 processzoros SGI C-téglát, elölről 
megismételve a teljes fejlesztési folyamatot. 

2002 közepére a fejlesztő csapat nagyszerű fejlődést mutatott: 
egyetlen processzor indításától eljutottak a 64 processzoros 
rendszer működéséig. Az Ítanium 2 lapkákkal felszerelt 
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64 processzoros rendszer ismét úttörőnek számított a maga 
nemében. Mindezek természetesen egyetlen rendszerlenyo- 
maton lévő (single system image) Linuxon futottak. 

Az egész folyamat alatt minden változtatást és hibát, amit csak 
a Linuxban találtunk, visszaküldtünk a rendszermagfejlesztők- 
nek, hogy a ja vításokat későbbi Linux-terjesztésekbe már 


beletehessék. 


Közelkép a Nagy Vasról 

Más Linux-fejlesztők gyakran kérdezik: , Miféle változtatásokat 
kellett alkalmaznotok a Linuxon, hogy egy ilyen méretű 
rendszeren fusson?" vagy , A Linux-processzor méretezhető- 
sége nincs nyolc vagy hasonló számú processzorra korlátoz- 
va?". Ahhoz, hogy válaszolhassunk ezekre a kérdésekre, előbb 
meg kell vizsgálnunk, mit használ az SGI programalapnak, 
milyen kitűnő változtatásokat végzett el a közösség, és hogy 
milyen más HPC-vel kapcsolatos fejlesztéseket és eszközöket 
adott az SGI, hogy a Linux messze túlszárnyalja az ismert 
nyolcprocesszoros határt. 

Az SGI Altix 3000 rendszerek rendszerprogramja az Itanium 
processzorokhoz szánt szabvány Linux-terjesztést és a Linuxot 
további képességekkel felruházó SGI ProPack bővítményt 
tartalmazza. Az SGI ProPack termék egy újabb 2.4 alapú Linux- 
rendszermagot, HPC könyvtárakat, amelyek az SGI alkatrészei- 
nek legjobb kihasználására vannak kiélezve, valamint NUMA- 
eszközöket és meghajtókat tartalmaz. 

Az SGI Altix 3000 rendszeren használt 2.4 alapú Linux-rend- 
szermag az Ítanium processzorokhoz szánt szabványos 2.4.19- 
es rendszermagot (kernel.org), illetve néhány továbbfejlesztést 
tartalmaz. Ezek a továbbfejlesztések három osztályba sorolha- 
tók: általános hibajavítások és felülettámogatás, fejlesztések 

a Linux-közösség más munkáiból, végül SGI-változtatások. 

A rendszermag-változtatások első csoportjába a kipróbálás alatt 
talált hibák javításai tartoznak, illetve az alapot képező felület 
továbbfejlesztései, valamint a NUMA-támogatás. Ezeket a 
változtatásokat az SGI a rendszermagot fejlesztő csapat megfe- 
lelő karbantartójával együttműködve végezte, hogy e módosí- 
tások visszakerülhessenek a rendszermag főáramába. 

A rendszermagfejlesztések második csoportjába azok a kitűnő 
munkák és teljesítményfoltok kerültek, amelyeket a közös- 
ségből mások fejlesztettek ki, de hivatalosan még nem 
fogadtak el, vagy átütemeztek a 2.5 fejlesztői vonalra. Ezek 

a fejlesztések a következő VA Software SourceForge lapokon 
találhatók meg: , Linux on Large Systems Foundry" 
(large.foundries.sourceforge.net) és a , Linux Scalability Effort 
Project" (sourceforge.net/projects/lse). Mi a projektekből a 
következő foltokat használtuk: a processzorütemezőt, a nagy 
rendszermagzár-felhasználást (Big Kernel Lock) csökkentő 
javítást, a Read-Copy-Update (olvass-másolj-frissíts) spinlock 
elven alapuló deache 1ock-usage csökkentésjavítást, 
illetve az FRlock zárolási elven működő xtime lock 
(gettimeofday) felhasználáscsökkentő fejlesztést. 

A Linux eszközkezelő fájlrendszerét (devís 

2 http:/www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html) 
is beállítottuk és használjuk, hogy a rendszerünkön elérhető 
rengeteg lemezt és KB sínt kezelhessünk. A devfs biztosítja 
számunkra, hogy az eszközelérési utak újraindítás után is 
megmaradjanak, mégha időközben lemezeket vagy vezérlőket 
helyeztünk be vagy távolítottunk is el. Az egyik legkellemetle- 
nebb dolog, amivel a nagy rendszerek gazdái találkozhatnak, 
ha az egyik rendszer tönkremegy, és hirtelen ötven, esetleg 
még több lemez átszámozódik és átneveződik. A devfs meg- 
bízhatónak bizonyult olyan különlegesen igénybe vett rend- 
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szerkörnyezetekben is, amelyekben akár 64 processzorral és 
rostcsatornák (Fibre Channel) tucatjaival rendelkező összeál- 
lítások működnek együtt százszámra befűzött lemezekkel. 

A devíés kiegészítő része a 2.4-es Linux-rendszermagnak, 

így további foltra nem volt szükség. 

A rendszermag-változtatások harmadik csoportjába kerültek az 
SGI által végzett módosítások, amelyeknek a Linux fővonalába 
történő illesztése jelenleg is folyik, s a 2.4-es változatkövetők- 
ben kapnak helyet, vagy a folt különleges felhasználási területe 
vagy természete miatt elkülönítve maradnak. Ezeket a nyílt 
forrású fejlesztéseket az ,Open Source at SGI" honlapon talál- 
juk (2 http://oss.sgi.com). Az általunk elvégzett módosítások 

a következők voltak: az XFS fájlrendszer-program, folyamat- 
aggregátumok (Process AGGregates, PAGG), CpuMemSets 
(CM5), rendszermag-nyomkövető (kdb) és a Linux rendszer- 
mag összeomláslistázó (Linux kernel crash dump, azaz Ikcd). 
Ezen felül az SGI beépítette az Írix alól áthozott SCSI alrend- 
szerét és vezérlőit. A Linux 2.4 SCSI K/B alrendszerrel végzett 
első kipróbálások megmutatták, hogy a terület komolyabb 
fejlesztése nélkül nem tudjuk vásárlóink jelentős tárigényeit 
kielégíteni. Bár a fővonalbeli rendszermagfejlesztők a későbbi 
kiadásokhoz már dolgoznak ezen a feladaton, az SGI[-nak 
azonnali megoldásra volt szüksége a 2.4 alapú rendszermagok- 
hoz, így az Irixről áthozott SGI XSCSI hátteret és meghajtókat 
használtuk ideiglenes megoldásként. 

A 3—5. ábra azt mutatja be, milyen kezdeti javulást értünk el az 
SGI Altix 3000 rendszeren futó Linux alatt a fent említett 
változtatásokat követően. A 3. ábra az XES fájlrendszert hason- 
lítja a többi Linux-fájlrendszerhez. (Megjegyzés: ha a Linux- 
fájlrendszerek teljesítményét összehasonlító részletesebb írást 
keresünk, nézzük meg a 2002-es Usenix Annual Technical 
Conference , Filegystem Performance and Scalability in Linux 
2.4.177 című cikket, amely az 3 http://oss.sgi.com lapról szintén 
elérhető). A 4. ábra az XSCSI-t hasonlítja 2.4-es Linux SCSI 
rendszeréhez, végül a 5. ábra az AIM7-el elérhető processzor 
méretezhetőségét szemlélteti. 

Bár az SGI inkább a nagyteljesítményű, illetve műszaki számítási 
környezetekre összpontosít — ahol a processzorciklusok többsége 
általában a felhasználói szintű kódra és alkalmazásokra fordító- 
dik, nem a rendszermagra - az AIM7 teljesítnménypróba megmu- 
tatta, hogy a Linux a főként az üzleti környezetekre jellemző, 
más típusú terhelés alatt is jól méretezhető. A HPC-alkalmazá- 
sok linuxos teljesítmény- és méretezhetőségi példáit a széljegy- 
zetben , Feladatmeghatározások valós környezetben" címmel 
olvashatjuk. 

A Stream Íriad teljesítménypróba segítségével az SGI meg- 
mutatta, hogy kettőtől 64 processzorig csaknem lineáris 
méretezhetőség érhető el, és eljutott a másodpercenkénti 
120 GB-os sebességig. Ez az eredmény jelentős mérföld- 
kőnek számít az iparban, hiszen új világrekordot állít fel 

a mikroprocesszor vezérelte rendszerek világában, és ezt 

az eredményt egy egyetlen rendszerlenyomatot futtató 
Linuxon értük el! Ez a lenyűgöző eredmény egyben azt is 
megmutatja, hogy a Linux a megszokott nyolcprocesszoros 
korlátozáson felül is ténylegesen jól használható. A Stream 
Iriadról további tájékoztatást a 

2 http:/www.cs.virginia.edu/stream oldalon olvashatunk. 
Ha megnézzük az SGI ProPackben felsorolt rendszermagfris- 
sítés-listáját, a felsorolást meglepően rövidnek találjuk majd, 
ami ékesen bizonyítja a Linux eredeti kitűnő tervezését. Ami 
talán még lenyűgözőbb, hogy e javítások nagy része már benne 
van a 2.5-ös fejlesztői rendszermagban. Azt mondhatjuk, hogy 
a Linux gyorsan HPC operációs rendszerré növi ki magát. 
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Egyéb változtatások a HPC Linuxon 

Az SGI ProPack tartalmaz pár olyan eszközt és könyvtárat, ame- 
lyekkel a nagy NUMA-rendszerek teljesítményét fokozhatjuk, 
ha olyan összetett feladatokat akarunk megoldani, amelyek sok 
processzort és memóriát használnak, vagy amikor több alkal- 
mazás fut egy időben ugyanezen a nagyrendszeren. Linux alatt 
az SGI a cpuset és a dplace parancsokat használja, amelyek 
jól becsülhető és fejlett CPU és memóriafelhasználás-vezérlést 
biztosítanak a HPC-alkalmazások felett. Ezek az eszközök segí- 
tenek nekünk kimetszeni a szükségtelen folyamatokat, segítenek 
úgy használni a minden feladathoz a szükséges erőforrásokat, 
hogy ne keresztezzék egymás útjait, illetve megakadályozzák, 
hogy a kisebb feladatok véletlenül nagyobb mennyiségű erőfor- 
rást pazaroljanak el, mint amennyit hatékonyan használni tud- 
nak. Ilyen módon a rendszer erőforrásait hatékonyan használjuk 
fel, és az eredményeket rendszeres időközönként kapjuk meg 

— ami két jellemzően kényes pontja a HPC-környezeteknek. 

Az SGI ProPackben található SGI Message Passing Toolkit 
(MP1I) az SGI számítógépekre optimalizált, ipari szabványú 
üzenetküldő könyvárat teszi elérhetővé. Az MPT-ben megtalál- 
juk az MPI és a SHMEM API-kat, amelyek átlátszóan helyezik 
üzembe és használják az SGI-alkatrészek alacsony szintű 
képességeit, például a gyors memóriá belüli másolásokhoz 
használt blokkátviteli motort (BIE), és a memóriaeszközvezér- 
ló-kiragadó művelet (fetchop) támogatását. A fetchop-támo- 
gatás közvetlen kapcsolattartást és összehangolást tesz lehe- 
tővé több MPI folyamat között, miközben semlegesíti az operá- 
ciós rendszer rendszerhívásaival kapcsolatos többletmunkát. 
Az SGI ProPack NUMA-eszközök, a HPC könyvtárak és a 
szabványos Linux-terjesztésre épített egyéb programtámogatás 
együtt hatékony HPC programozási környezetet jelent a nagy 
számítás- és adatigényű munkaterhelésekhez. Ahhoz hason- 
lóan, ahogy az egyedi ASIC , ragasztólogikaként" felhasznál- 
hatóvá teszi a processzorokat, a memóriát és a K/B részeket 

az alkatrészeken, az SGI ProPack program ahhoz biztosítja a 

, ragasztó logikát", hogy a Linux operációs rendszert a nagy 
HPC-környezetek általános építőkövévé tegye. 


Osszefoglalás 

Senki sem hitte volna, hogy a Linux ilyen jól és ilyen hamar 
méretezhetővé válik. A Linux és az SGI NUMAftflex rendszer- 
kiépítés ötvözésével, valamint az Itanium 2 processzorokkal az 
SGI megépítette a világ legerősebb Linux-rendszerét. Az SGI 
Altix 3000 rendszer piacra viteléhez rengeteg erőfeszítés kellett, 
és úgy véljük, ez még csak a kezdet. Az SGI által folytatott 
kemény szabványalapú stratégia, amit az Ítanium 2 alapú 
rendszereken futó Linuxoknál használt, feljebb helyezi a Linux 
képességeit jelző lécet, miközben vásárlóinak érdekes, megal- 
kuvások nélküli választási lehetőséget kínál a HPC-kiszolgálók 
és szuperszámítógépek terén. Az SGI mérnökei - így tulajdon- 
képpen a teljes cég — tökéletesen megbízik a Linux képességei- 
ben és folytatni szeretné a megkezdett utat, még több érdekes 
áttörést hozva a Linux- és a HPC-közösségnek. 


Linux Journal 2003. február, 106. szám 


Steve Neuner 

Az utóbbi 19 évben Unix-rendszermagfejlesztése- 
ken dolgozik. Jelenleg az SGI-nál Linux-mérnök- 
igazgató, és négy éve, amióta csatlakozott 

az SGI-hoz, Linuxon és Itanium alapú rendszereken 
dolgozik. 


Fák a Reiser4 fájlrendszerben (1. rész) 


Az új ReiserFS felépítése - fák, csomópontok, kulcsok és cikkelyek. 





z adatszervezés egyik módja az, ha fákban helyez- 
AA zük el őket. Ha egy számítógépen adatokat ren- 

dezünk, rendszerint úgynevezett halmokban, vagyis 
csomópontokban helyezzük el őket, amelyek mindegyike 
tartalmazza a többi halom nevét (vagyis mutatóikat). A cso- 
mópontok némelyike mutatókkal rendelkezik, ezeket végig- 
böngészve általában azt találjuk, hogy más hasonló csomó- 
pontokra mutatnak. 
Minket elsősorban a szervezési rész érdekel, így a dolgokra akkor 
bukkanhatunk rá, ha keressük őket. A fa egy szervezési módszer, 
amely ennek megfelelő tulajdonságokkal rendelkezik. Ennek 
következtében a fát a következők alapján határozzuk meg: 


1. A fa csomópontok sokaságából áll, melyeket a gyökércsomó- 
pont köt össze; és nulla vagy több csomóponttal rendelkezik, 
amelyeket részfáknak hívunk. 

2. A részfák mindegyike önállóan is fát alkot. 

3. A fa egyetlen pontja sem mutat a gyökércsomópontra, és 
a csomópontból minden egyes nem gyökércsomópontra 
egyetlen mutató irányul. 

4. A gyökércsomópont az összes részfájára, vagyis a részfákhoz 
tartozó gyökércsomópontokra rendelkezik mutatóval. 


Az egyetlen pontból álló, mutatók nélküli csomópontot is fának 
nevezzük, mivel az egy gyökércsomópont. Hasonlóképpen 
fának nevezzük az egymásból egyenesen kiinduló, elágazások 
nélküli csomópontokat is. 


A meghatározás sarokpontjai 

Érdekes dolog azon vitatkozni, hogy vajon a véges is a fák 
meghatározásai közé tartozik-e. Fákat többféle módon határoz- 
hatunk meg, és a legjobb meghatározás mindig a célfeladattól 
függ. Donald Knuth professzor is többféle meghatározást hasz- 
nál a fákra. Elsődleges meghatározásaként egy olyan fát mutat 
be, amelynek egyáltalán nincsenek mutatói, se élei, se össze- 
kötővonalai, se egyebei — egyszerűen csak csomópontokból áll. 
Knuth a fát véges számú csomópontok halmazaként határozza 
meg. Az Interneten a végtelen fákról is lehet találni írásokat. 
Úgy gondolom, sokkal megfelelőbb a végest mint tulajdonsá- 
got használni, semmint beleerőszakolni a meghatározásba - bár 
kutatásaimban csak véges fákkal foglalkozom. 

Ha fákkal foglalkozunk, gyakran találkozhatunk az él fogalmá- 
val. A mutató egyirányú, ami azt jelenti, hogy a mutató követ- 
hető abból a csomópontból, ahonnan kiindul, de a folyamat 
visszafelé nem lehetséges. Nem lehetséges egy csomópontból 
visszakövetni, hogy melyik másik csomópontból hivatkoznak 
rá. Ennek megfelelően az él kétirányú, vagyis mindkét irányból 
nyomon követhető. 

Az alábbiakban három különböző fameghatározást sorolunk 
fel, melyekben az a különös, hogy matematikai szempontból 
mégis egyenlők. Az általam felvázolt meghatározásnak azon- 
ban nem felelnek meg, mivel az él nem egyezik meg a muta- 
tóval. Mindhárom meghatározás esetén legyen egyetlen él, 
amely ugyanazt a két csomópontot köti össze: 
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e  Élekkel összekötött csúcsok (vagyis pontok) esetében az 
élek száma pontosan eggyel kevesebb, mint a csúcsok 
száma. 

e Csúcsok élekkel összekötött halmaza, mely nem tartalmaz 
kört (körnek nevezzük a csúcsból önmagába visszahajló 
összekötővonalat). 

e Csúcspontok csoportját, amelyeket élek kötnek össze, és 
két csúcspont csak egyetlen útvonalon érheti el egymást. 


Ezekben a meghatározásokban a fáknak nincsen egységes 
gyökerük, és az ilyen fákat szabad fáknak hívjuk. 

Az általam használt meghatározás egy gyökérrel rendelkező fát 
takar, nem egy szabad fát, amelyben nincsen kör sem, és pont 
eggyel kevesebb mutatóval rendelkezik, mint ahány csomó- 
pontja van, emellett minden csomópont bármely másikat csak 
egyetlen útvonalon érhet el. 


Gráf vagy fa? 

Vedd sorba azokat a feladatokat, amelyeket inkább gráf segít- 
ségével oldanál meg, és azokat, amiket fa segítségével valósí- 
tanál meg. Egy fában a fa minden egyes csomópontjához a 
gyökérből kiindulva csak egyetlen útvonal létezik, ezenkívül 
a fa minimális követelménnyel rendelkezik a mutatók számát 
illetően, hogy minden csomópontot össze lehessen kapcsolni. 
Ez teszi a fát egyszerű és hatékony szerkezetté. A fák akkor 
használatosak, amikor kevésbé bonyolult és hatékony szerke- 
zetre van szükségünk, ahol nem jelent gondot, hogy minden 
csomópontot csak egyetlen útvonalon érhetünk el. A Reiser4 
fákat és gráfokat egyaránt használ. Fákat olyankor, ha a fájl- 
rendszer választja ki a szükséges szerkezetet (ezt hívjuk táro- 
lási rétegnek, amelynek egyszerűnek és hatékonynak kell 
lennie), és gráfokat, amikor a felhasználó választja ki a szüksé- 
ges szerkezetet (a tartalmi szinten, melynek sokoldalúnak kell 
lennie, hogy a felhasználó azt tehesse, amit csak akar). 


Kulcsok 

A fában minden elemhez kulcsot rendelünk, ennek alapján 
találjuk meg a keresett elemeket, használatuk pedig óriási 
rugalmasságot biztosít a dolgok rendezésekor. Ha a kulcsok 
rövidek, akkor kevés adat birtokában is megtalálhatjuk, amit 
keresünk. Azt is behatárolja egyúttal, hogy milyen adatok 
alapján kereshetjük meg a dolgokat. 

Ez a határ korlátozza a kulcs használhatóságát, emiatt rendel- 
kezünk egy tárolási réteggel, ami a dolgokat a kulcsok alapján 
keresi meg, és egy tartalmi réteggel, ami nagyon gazdag elne- 
vezési rendszerrel rendelkezik (erre cikkünk 2. részében térünk 
ki). A tárolási réteg csak a tároló megszervezésére használ 
kulcsokat, így növelve a teljesítményt, ugyanakkor a tartalmi 
réteg olyan nevekkel dolgozik, amelyeknek a felhasználó szá- 
mára jelentése van. lalán felteszed a kérdést, hogy vajon ez 

a megfelelő elrendezés-e, olyan, ami biztosítja a szabadságot, 
hogy újabb dolgokat adjunk a tárolási réteghez, így növelve 
teljesítményét — ugyanakkor a tartalmi réteg elnevezéseinek 
kezelésekor el kell viselnünk a mellékhatásait. 
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A részfa kiválasztása 

A gyökérnél kezdjük a keresést, mivel innen az összes csomó- 
pont elérhető. De hogyan dönthetjük el, hogy a gyökérből elin- 
dulva melyik részfán folytassuk az utunkat? A részfákra a 
gyökérben található mutatók segítségével juthatunk el. Minden 
egyes részfára irányuló mutatóhoz tartozik egy bal oldali körül- 
határoló kulcs. A részfákra irányuló mutatók és maguk a rész- 
fák is baloldali körülhatároló kulcsuk szerint vannak rendezve. 
Egy részfa mutatójának a bal oldali körülhatároló kulcsa meg- 
egyezik a részfában található legkisebb kulccsal. Ennek a jobb 
oldali körülhatároló kulcsa nagyobb, mint a részfa legnagyobb 
kulcsa, és ez a csomópont következő alfájának a bal oldali 
kulcsa is egyben. 
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2. ábra Olvasási teljesítmény 
(a 2.4.18-as rendszermag forráskódját beolvasva) 


Az egyes részfák csak olyan dolgokat tartalmaznak, amelyek- 
nek vagy a mutatójukhoz tartozó bal oldali körülhatároló 
kulcsa legalább egyenlő, vagy a jobb oldali körülhatároló kulcsa 
legfeljebb ilyen nagyságú. Ha a részfában nincsenek többszö- 
rösen előforduló elemek, akkor minden részfa csak olyan dol- 
gokat tartalmaz, amelynek a kulcsai kisebbek a jobb oldali 
körülhatároló kulcsánál. Ha nincsenek kettőződések, akkor egy 
csomópont részfákra irányuló mutatóinak és azok körülhatá- 
roló kulcsainak alapján egyértelműen eldönthető, hogy melyik 
ág tartalmazza a keresett dolgot. 

A többszörösen előforduló kulcsokról egy másik alkalommal 
lesz szó. Most csak annyit jegyeznék meg, hogy először a rész- 
fák között a kettőzött kulcsú elem egyik kulcsát kell megtalálni, 
majd az ehhez tartozó párokat kell egyesével végigvizsgálni, 
mígnem megtaláljuk a megfelelő elemet. A kettőzött kulcsokkal 
kisebb méretű kulcsokhoz jutunk, így alkalomadtán egyetér- 
tésre juthatunk a kulcsok méretét és az ilyen nem hatékony ke- 
resések mennyiségét illetően. A fa minden csomópontjában a 
rendezés a csomópontokon belül zajlik. Ennek alapján az egész 
fát kulcsok szerint rendezzük, így bármely kulcs birtokában 
tudjuk, hol keressük a kulcshoz tartozó elemek egyikét. 
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Csomópontméret 

A csomópontok méretét egyformának választjuk, így könnyebb 
meghatározni a csomópontok közti szabad területet, mivel az 

a csomópont méretének valahányszorosával lesz egyenlő. Ilyen 
módon nem okoz gondot, ha rendelkezünk ugyan hellyel, de 

a rendelkezésre álló hely túlságosan kicsi egy csomópont táro- 
lásához. Emellett a merevlemezek olyan csatolófelülettel ren- 
delkeznek, ami feltételezi az egyenlő méretű szakaszokat, ami 
kényelmesen illeszkedik a hibajavító műveletekhez. 

Ha nem fontos, hogy a csomópontok egyforma méretűek 
legyenek, mert mondjuk elférnek a RAM-ban, érdemes lehet 
egy pillantást vetnünk az átugró listákra. 

A Reiser4 csomópontjai alapesetben a lapmérettel egyeznek 
meg, amely - ha Linuxot használsz Intel processzorral — 4 k 
(4096 bájt). Semmilyen tapasztalati bizonyíték nem támasztja 
alá, hogy ez a méret jobban megfelelne, mint bármely másik; 
az egyetlen indok, amiért mégis ezt használjuk, az az, hogy a 
Linux ezt teszi a legegyszerűbben programozhatóvá. Az igazat 
megvallva: inkább csak nem volt még időnk egyéb méretekkel 
kísérletezgetni. 


Takarékoskodjunk a hellyel 

Ha a csomópontok mérete megegyezik, hogyan tároljunk 
nagyobb dolgokat? Darabokra vagdossuk őket: az így 
létrejövő darabokat cikkelyeknek (item) hívjuk. A cikkely 
mérete pont akkora, hogy elférjen egyetlen csomópontban. 
A hétköznapi fájlrendszerek az állományokat teljes szaka- 
szokban tárolják. Ez körülbelül annyit jelent, hogy fájlonként 
egy fél szakaszt elveszítünk. Ha a fájl jóval kisebb, mint a 
szakasz mérete, akkor a veszteség a fájl méretének sokszorosa 
is lehet. Ennek következtében nem ajánlatos szokványos 
adatbáziselemeket (címek, telefonszámok) tárolni ilyen 
hétköznapi fájlrendszeren, mivel az elfoglalt terület legalább 
90 százaléka kárba vész. Azáltal, hogy a Reiser4-ben egyetlen 
csomópontban több dolgot is képesek vagyunk tárolni, 

az is lehetséges, hogy egy-egy szakaszt több kisméretű fájl 
között osszunk meg. Hatékonyságunk a kisméretű fájlok 
helykihasználását illetően megközelítőleg 94 százalék. 

Ez a szám természetesen nem tartalmazza a fájlonkénti 
többlettárhelyet, ami függ az egyes fájlok méretétől, emiatt 
nehezen megbecsülhető. 

A fájlok 4 k-s szakaszméretre igazítása azonban nagy fájlok 
esetén kifejezetten előnyös. Ha egy program közvetlenül 
szeretne egy fájllal dolgozni, tehát anélkül, hogy különféle 
rendszerhívásokhoz kellene folyamodnia, használhatja az 
mmap () függvényt, amellyel a fájl tartalma közvetlenül az 
alkalmazás címteréből válik elérhetővé. Bizonyos megvaló- 
sítási tényezőkből következően az mmap () megköveteli, 
hogy a fájl tartalma 4 k-s határra legyen igazítva. Ha az ada- 
tok már eleve 4 k-ra vannak igazítva, az nagymértékben 
felgyorsítja az mmap ( ) -ot. A jelenlegi alapértelmezés szerint 
a Reiser4-ben a 16 k-nál nagyobb fájlok 4 k-s határra vannak 
igazítva. Jelenleg azonban még nem rendelkezünk elég 
tapasztalattal és adatokkal ahhoz, hogy meg tudjuk ítélni, 

a 16 k-s fájlméret valóban megfelelő-e. 


Levelek, ágak, gallyak 

Fás hasonlatunknál maradva, a levelek gyermekkel nem 
rendelkező csomópontok. A belső csomópontok alatt a gyer- 
mekkel rendelkező csomópontokat értjük. 

A keresés a gyökérnél kezdődik, ezt követően bejár két belső 
csomópontot, majd egy levélen fejezi be az útját, mely egy 
adatokat tartalmazó csomópont, gyermekek nélkül. A cikkely 
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egy adattároló szerkezet, ami teljes egészében egy szakaszon 
belül helyezkedik el. Azt a csomópontot, ami cikkelyeket tar- 
talmaz, formázott csomópontnak nevezzük. Ha dolgokat táro- 
lunk egy fában, az egyes darabokat cikkelyekben és formázat- 
lan levelekben tároljuk el. Formázatlan leveleknek hívjuk az 
olyan leveleket, amelyek semmilyen formázási adatot nem 
tartalmaznak, csakis adatot. Egyedül a levelek tartalmazhatnak 
formázatlan adatokat. A mutatók cikkelyekben tárolódnak, 
ennek követeztében minden belső csomópont egyúttal 
szükségképpen formázott csomópont is. 

A formázott csomópontokra irányuló mutatók különböznek 

a formázatlan levelekre irányulókról. A jobb megértés kedvéért 
vegyük a következő példát: a fokmutatók formázatlan leve- 
lekre hivatkoznak. Foknak nevezzük az egymást követő, szom- 
szédos, szakaszon belüli vagy szám szerint egymást követő, 
egyazon dologhoz tartozó formázatlan leveleket. A fokmutató 
tartalmazza a kezdő szakasz számát és a hosszt. Mivel a fok 
csak egyetlen dologhoz tartozik, a fokhoz csak egyetlen kulcsot 
tárolhatunk, és még ezután is kiszámolhatjuk minden egyes 
bájtnak a kulcsát a fokon belül. Ha a fok legalább két szakasz 
hosszúságú, a fokmutatók sokkal tömörebbek, mint az 
általános csomópontmutatók. 

A csomópontmutatók formázott csomópontokra irányuló 
mutatók. Jelen pillanatban még nem rendelkezünk a csomó- 
pontmutatók tömörített változatával, de hamarosan elkészül- 
nek. Fontos, hogy fokmutatók esetén nem szükséges tárolni 

a hivatkozott csomópontok körülhatároló kulcsait, míg a cso- 
mópontmutatók használatakor ez muszáj. Valószínűleg a tömö- 
rített kulcsok a tömörített csomópontmutatókkal egyidőben 
kerülnek bemutatásra. Valaki talán azt várná, hogy a kulcsok 
tömörítve legyenek, csak azért, mert növekvő sorrendbe 
vannak rendezve. Szeretnénk, ha csomópont- és cikkelybővít- 
ményeink ilyen tulajdonságokkal valamikor a későbbiekben 
egyszerűen kiegészíthetővé válnának. 

A gallyak a levelek szülői, és a fokmutatók csakis gallyakban 
léteznek. (Ez egy elég vitatott tervezési elmélet, amelyet a cikk 
következő részében még tárgyalunk.) Az ágak belső csomó- 
pontok, és nem egyeznek meg a gallyakkal. 

Azt hihetnéd, hogy a gyökeret egyszerűen első szintnek is 
nevezhetnénk, de mivel a fa a felszínen nő, sokkal ésszerűbb 
első szintnek nevezni azt a részt, ahol a levelek is találhatók és 
az adatok tárolódnak. A fa magassága attól függ, hogy hány 
dolgot kell tárolnunk benne, és hogy a belső és gallycsomó- 
pontok hány gyermekkel rendelkeznek. 


A cikkelyek típusai 

A Reiser4 többféle típusú cikkelyt tartalmaz a különféle típusú 
adatok tárolásához: 

static stat data: a tulajdonost, a jogosultságokat, az 
utolsó hozzáférés idejét, a létrehozás idejét, az utolsó módosí- 
tás idejét, a méretet és a fájlra mutató hivatkozások számát 
tartalmazza. 

cmpnd dir item: a könyvtárbejegyzéseket és a fájlokra 
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mutató kulcsokat tartalmazza. 

Fokmutatók: lásd feljebb. 

Csomópontmutatók: lásd feljebb. 

Törzs: a fájlnak azon részét tartalmazza, ami nem elég nagy 
ahhoz, hogy egy különálló formázatlan levélben tárolódjon. 


Egységek 

Egységnek nevezzük azt az elemet, amelyet teljes egészében 

egy cikkelyben kell elhelyeznünk, anélkül, hogy több cikkely 

között szétdarabolnánk. Egy cikkely tartalmát gyakran egysé- 
gekben egyszerűbb végigolvasni: 
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e A törzsben található cikkelyek esetén az egység a bájt. 

e Könyvtárcikkelyek esetén az egység az egyes bejegyzéseket 
jelenti. A könyvtárbejegyzések tartalmazzák a fájl nevét és 
kulcsát (amelyek a gyakorlatban akár tömörítettek is 
lehetnek). 

e — Fokcikkelyek esetén az egység a fok. Fokcikkelyek csak 
az adott fájlhoz tartozó fokokat tartalmaznak. 

e Astatic stat data számára az egész statisztikai adat 
egyetlen oszthatatlan, rögzített méretű mezőt képez. 


Összegzés 

Elmagyaráztam a Reiser4 fa alapvető szerkezeteit, de az igazán 
szórakoztató rész még csak most következik. Még nem magya- 
ráztam el, hogy más kutatók hogyan alakítják a fáikat, és még 
azt sem tudod, hogy az elemek tartalma miért a fa alján helyez- 
kedik el, miért szükséges a pontos elkülönítés, és miért van 
szükség különféle kiegyenlítőkre. Még csak nem is utaltam 
eddig arra, hogy miért jobbak a kiegyensúlyozott fák, és hogy 
miért a táncoló fa a legjobb. Amiről pedig aztán végképp nem 
beszéltem, az az, hogyan változik meg egy bonyolult és vitatott 
faszerkezet, amelyet ebben a cikkben is bemutattunk, úgy, 
hogy a Reiser4 kétszer gyorsabban olvasson, mint a Reiser3. 

Az erről szóló írás — helytől függően - a Linux Journal követ- 
kező számában fog megjelenni. 


Forrás 
Donald E. Knuth A számítógép-programozás művészete 


Linux Journal 2002. december, 104. szám 


Hans Reiser (reiseronamesys.com) 

Záró dolgozatát a nehéz tudományok és a számítástudomány 
elnevezési rendszert is kifejlesztett. Ezt a rendszert még most Is 
fejleszti, ahol is a Reiser4 képezi a tárolási réteget. 1993-ban 
Oroszországba utazott, hogy összeszedjen egy programozókból 
álló csapatot, és belefogjanak a ReiserFS fejlesztésébe. 1999 körül 
a rendszer olyannyira jól kezdett működni, hogy édesanyja 
felhagyott az unszolással, hogy a fia valamilyen jól fizető állást 
keressen egy nagy cégnél. 
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Dióhéjban az ext3 fájlrendszerről 


Ha biztonságban szeretnénk tudni féltett adatainkat, 
használjunk valamilyen naplózó fájlrendszert, például az ext3-at. 


Linux ,hagyományos" fájlrendszere az ext2. Ez egy 
AA jól kipróbált, megbízható rendszer, azonban akad egy 

gyenge pontja: érzékeny a hirtelen leállásokra. Az 
ext2 a hatékonyság növelése érdekében a merevlemezt úgy- 
nevezett aszinkron módban használja. Ennek az a hátránya, 


hogy ha az adatátvitel akár csak egyetlen pillanatra is megsza- 
kad, fennáll az adatvesztés kockázata. 


A metaadatok szerepe 

Az, hogy történik-e adatvesztés, csak azon múlik, hogy 

mikor következett be a hirtelen leállás. Ha az adatok lemezre 
mentése után történik, akkor nincs is semmi baj, megúsztuk. 
Ha a kiírás előtt, akkor sajnos az új (még ki nem írt) adatok 
örökre elvesznek, de legalább a régiek megmaradnak. A leg- 
rosszabb eset az, amikor pont az írás folyamata közben követ- 
kezik be a sajnálatos esemény. Ekkor ugyanis könnyen 
előfordulhat az, hogy az állomány első fele az új, a másik fele 
még a régi adatokat tartalmazza. Ez rendkívül kellemetlen, de 
korántsem annyira, mint amikor az úgynevezett metaadatok 
írásakor áll le a rendszer. A metaadatok olyan adatok, ame- 
lyeknek a nyilvántartását a lemezen lévő állományokról maga 
a fájlrendszer végzi. Ilyen például a fájl neve, a mérete, létre- 
hozásának a dátuma, a jogosultságok és a legfontosabb: hogy 
hol helyezkedik el a lemezen. Ha a metaadatok nem tudnak 
rendesen kiíródni, az is előfordulhat, hogy az egész fájl 
örökre eltűnik. 

Azért nincs minden veszve, mert a legtöbb esetben (ha nem is 
teljes mértékben) helyreállítható a károsodás. Erre szolgál az 
fsck nevű program is, ami minden szabálytalan leállítás után 
a rendszer indulásakor önműködően elindul. Ez egy fájlrend- 
szerelemző program, ami az esetleges hibákat próbálja meg 
felderíteni és helyreállítani a fájlrendszerben. Amennyiben a 
metaadatok megsérültek, általában vissza lehet állítani őket, 

ha volt róluk másolat. Ha nem volt, akkor a sérült állomány 
tartalma véglegesen elveszett. 

Ezekután kétségtelen, hogy aki létfontosságú adatokat ext2-n 
tárol, az a tűzzel játszik (hacsak nem tart otthon szünetmentes 
tápot — bár hirtelen leállást más is okozhat, nem csak áramszü- 
net). A másik nagy gond az ext2-vel az, hogy az fsck-val 
történő ellenőrzés időigényes, bizonyos esetekben több óráig is 
eltarthat. Ez különösen kellemetlen lehet egy hálózati kiszol- 
gáló esetében, ugyanis amíg az ellenőrzés tart, addig nem tudja 
ellátni a feladatait. 


A naplózó fájlrendszerek áttekintése 

Mi lehet a megoldás? Használjunk úgynevezett naplózó 
(journaling) fájlrendszereket. 

Az ezek mögött meghúzódó alapgondolat az, hogy mielőtt 
az írási műveletet végrehajtanánk a lemezen, egy csakis erre 
a célra fenntartott területre (a naplóba) beírjuk, hogy mit 
kellene elvégeznünk. A napló tulajdonképpen egy adatbázis, 
amelybe szekvenciálisan írjuk be a lemezen elvégzendő 
változtatásokat. 
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A fájlrendszer olvasási, illetve írási sebességét mutatja 
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Mit nyerünk ezzel? legyük fel, egy hirtelen leállás történik. 

A rendszer újraindítása után a fájlrendszer ellenőrzi a naplót. 
Ha nem talál benne új bejegyzést, akkor két dolog lehetséges: 
vagy minden írási művelet befejeződött, vagy a leállás még 

az új művelet naplóba történő felvétele előtt bekövetkezett. 

Az utóbbi esetben az új adatok sajnos véglegesen elvesztek, 

de a régiek sértetlenül megmaradnak. 

Amennyiben új bejegyzést talál a naplóban, akkor a leállás 
minden bizonnyal a lemezre való írás pillanatában követ- 
kezett be. Ilyenkor azonban nem kell számolnunk az ext2 
esetében előforduló adatvesztés lehetőségével, mivel a 

napló segítségével a fájlrendszer a félbe maradt műveletet 

be tudja fejezni. Ez az egész folyamat nem tarthat tovább 

pár másodpercnél, tehát az órákig tartó , tsckázásnak" is 
búcsút inthetünk. 

A naplózó fájlrendszerek másik előnye, hogy sok esetben 
gyorsabbak, mint némely hagyományos fájlrendszer. Az írási 
kérések ugyanis rendszerint a lemez különböző helyein lévő 
blokkokra érkeznek, így a fejet állandóan pozícionálni kell. 
Ez komoly visszaesést jelent a teljesítményben. A naplózó fájl- 
rendszerek esetében először mindig szekvenciálisan a napló- 
ba írunk, így a fejet több írási művelet esetén is csak egyszer 
kell pozícionálni. A naplóban feltüntetett tranzakciókat pedig 
ráérünk elvégezni akkor, amikor a lemeznek nincs más feladata. 
A naplózó fájlrendszerekre jellemző még, hogy nem annyira 
szétszórtan tárolják az állományokat, mint más fájlrendszerek. 
Ezenkívül különböző egyszerűsítéseket és javításokat is végez- 
nek. Példaként említhetjük, hogy az AIX fájlrendszere például 
a kis könyvtárak tartalmát a fájlleíróban (i-node) tárolja. 

A naplózó fájlrendszer tehát jó dolog. Nézzük, milyen kínálat 
áll belőlük rendelkezésre Linux alá. Használhatjuk az IBM által 
kifejlesztett, az OS/2 megvalósításra épülő JFS-t (lásd még a 
22-25. oldalon). Ezzel a legnagyobb gond az, hogy a többihez 
képest viszonylag kevés segédprogram lelhető fel hozzá. 


Az XES szintén egy másik rendszerből átültetett naplózó fájl- 
rendszer. Ez az SGI IÍrix nevű operációs rendszeréből szárma- 
zik, és számos alkalmazás támogatja. A ReiserFS egy szintén 
nagyon megbízható fájlrendszer, fejlesztése folyamatosan zajlik 
(bővebben a 34-36. oldalon olvashatunk róla). 

A fenti fájlrendszerek fejlesztésével (illetve azoknak Linuxra 
történő átültetésével) párhuzamosan egy másik naplózó 
fájlrendszer is megjelent, az ext2-vel teljesen együttműködő 


ext3 fájlrendszer. 


Egy ANSI SOL relációsadatbázis-műveleteket mérő próba 
AS3ZAP 


nm EXT2 

m EXT3 

a Reiser 
c IBM JFS 
HI RAW 


o 
1 
fő 
o. 

ö 
o 
9 

6 
E 


Az ext3 kifejlesztésére több okból is szükség volt. Először is 

a Linux-felhasználók többsége ext2-t használt, ezen tárolták 
több gigabájtnyira duzzadt adataikat. Ahhoz, hogy egy másik, 
korszerűbb fájlrendszerre térjenek át, meg kellett oldaniuk 
adataiknak egy másik lemezrészre történő mentését, majd az 
átftormázás után az adatok visszamásolásának is zökkenőmen- 
tesen kellett mennie. Aki már csinált ilyet, tudja, hogy elég 
körülményes művelet. (Nem is beszélve arról, ha az adatok 
mellett a kérdéses lemezrész magának a rendszernek is az 
otthona.) Másrészt az ext2 akkorra már kiforrott fájlrendszer 
volt, a felhasználók többsége bízott benne. 

Így nem csoda, ha örömmel fogadtak egy olyan naplózó 
fájlrendszert, amelyik megbízhatóan együttműködik az ext2- 
vel. Ez azt jelenti, hogy a felhasználó egy egyszerű művelet 
segítségével — a rendszer működése közben - régi fájlrend- 
szerét ext3-ra alakíthatja át, anélkül, hogy adatai ideiglenes 
tárolásáról gondoskodnia kellene. Sőt az ext3 bármikor 
visszaalakítható ext2-vé. 

A másik nem elhanyagolható pozitív tulajdonsága az ext3-nak 
az, hogy megszabadulhatunk az fsck-val történő állandó le- 
mezellenőrizgetésektől. Egy hirtelen leállás utáni ellenőrzés, 
illetve az esetleges hibák kijavítása egy több gigás lemezrész 
esetében akár órákat is igénybe vehet. Az ext3 használatakor 
ez a művelet azonban nem tarthat tovább, mint pár másodperc. 
Az igazsághoz hozzátartozik az is, hogy az ext3 igazából nem 
egy teljesen új fájlrendszer. Valójában nem más, mint az eredeti 
ext2 kibővítése a naplózó szolgáltatással. A napló itt nem más, 
mint egy különleges rejtett állomány a gyökérben. 

Ennek a megoldásnak az az ára, hogy az ext3 nem tartalmaz 
olyan lemezgyorsító szolgáltatásokat, mint a többi korszerű 
fájlrendszer. Elméletileg azonban így is gyorsabb az ext2-nél, 
mert hatékonnyá teszi a fej mozgását. (A különböző sebesség- 
mérő próbák ez ügyben azonban nem mindig szolgálnak 
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meggyőző bizonyítékkal.) 
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Atállás ext2-róől ext3-ra 

A továbbiakban az ext3-as fájlrendszerrel fogunk foglalkozni, 
mivel erre pár másodperc alatt bárki , áttérhet", és a Red Hat is 
ezt a fájlrendszert támogatja. Megnézzük, miképp formázha- 
tunk egy üres lemezrészt, illetve hogyan alakíthatjuk át meg- 
lévő ext2-es fájlrendszerünket ext3-sá. 

Mindenekelőtt a rendszermagnak támogatnia kell az ext3 
fájlrendszert. A 2.4.15-ös rendszermagtól kezdve minden 
változatban megtalálhatjuk, ha ennél régebbi rendszermagunk 
van, akkor külön foltot kell letöltenünk. Ezt a 

2 http:/www.zip.com.au/—akpmy/linux/ext3/ címről tehetjük 
meg. A foltot másoljuk be a rendszermag forrását tartalmazó 
könyvtárba, majd ugyaninnen adjuk ki a következő parancsot: 


gunzip c ext3-2.4-x-y.gz ] patch -pi 


Az x az ext3 folt változatszámát, az y pedig a rendszermag 
változatát jelöli. 

Vigyázzunk arra, hogyha a gyökérlemez is ext3-as, akkor 
semmiképp se fordítsuk a támogatást modulba. A másik dolog, 
amire fel szeretnénk hívni a figyelmet: lehetőleg ne használjuk a 
rendszermagban található általános tárkorlát-támogatást (guota) 
az ext3-as fájlrendszerrel, mert rendszeromlást okozhat. Ha 
tárkorlátot szeretnénk használni, telepítsük az Alan Cox-féle -ac 
foltokat, amivel efféle baleset elvileg nem fordulhat elő. 

A rendszermagoldali támogatáson kívül szükségünk lesz még 
két csomagra is. Az első a uti1- linux, ami minden bizonnyal 
már telepítve is van. Arra figyeljünk, hogy ne legyen 2.11-nél 
idősebb változatú. A másik csomag az e2fsprogs névre 
hallgat, ez is megtalálható az összes terjesztésben. 

Az ext3 lemezrészt az mke2fs program segítségével 
hozhatunk létre a következő módon: 


mkelfs -j /dev/eszk z 


Egy meglévő ext2-es lemezrész átalakításához a tune2fs-t 
használhatjuk: 


tune2zfs -j /dev/eszk z 


Ez a művelet semmiféle adatvesztést nem okozhat. 

Az ext2 lemezrész átalakítása után ne felejtsük el a /etc/fstab 
állományt módosítani: a megfelelő bejegyzésnél a fájlrendszer 
típusa oszlopot (ez a harmadik) változtassuk ext3-ra. 
Minden mást úgy hagyhatunk, ahogy volt. Nem árt még 
leállítanunk az önműködő fsck-ellenőrzést, mivel az ext3 
ezt nem igényli: 

tune2fs -i 0 -c 0 /dev/eszk z 

(a -i kapcsoló azt mondja meg, hogy az Ífsck milyen gyakran 
fusson le másodpercként. A -c kapcsolóval pedig azt 
állíthatjuk be, hogy hány befűzés után fusson le az fsck 
önműködően). 

Ha valaki valamilyen okból kifolyólag a fájlrendszerét vissza 
szeretné állítani ext2-esre, a /etc/fstab visszaírása után a fent 
említett módon állítsa be az fsck-ellenőrzések gyakoriságát. 


Garzó András (garzoandOinterware.hu) 

Körülbelül három éve foglalkozik Linux- és más Unix-rendszerekkel. 
Legjobban az operációs rendszerek lelkivilága érdekli, de nyitott 
egyéniség. Kedvenc étele a palacsinta, és van egy Richard nevű 


macskája. Minden észrevételt, megjegyzést, levelet szívesen fogad. 
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Teljes értékű levelezőrendszer 


, 


Epítsünk több tartományt kezelő SMI P-levélkiszolgálót egyetlen gépen. 


ár e cikket útmutatónak szántuk, amelynek alapján a 
B Postfix, az OpenLDAP és a Courier-IMAP segítségével 

felépíthetjük a saját teljes levelezőkiszolgáló rendsze- 
rünket, azzal nem foglalkozunk, hogyan választottuk ki épp 
ezeket az összetevőket, hiszen ennek kifejtése önmagában 
megérne egy cikket. Célunk, hogy egyetlen gépen állítsunk fel 
egy több tartományt kezelni képes SMIP-levélkiszolgálót, 
távoli IMAP-eléréssel. 
Azt szeretnénk, ha nemcsak a héjprogram-azonosítóval rendel- 
kező emberek számára kézbesítenének leveleket, hanem a 
héjprogram-azonosítóval nem rendelkező embereknek is 
lehetne IMAP-azonosítójuk. Így az azonosítókat két osztályba 
soroljuk: helyi és virtuális osztályba. A helyi azonosítók azok, 
amelyeknek van parancsértelmező elérésük. Ők a saját felhasz- 
nálónevüket és jelszavukat használhatják az IMAP elérésére. 
A virtuális azonosítókhoz olyan felhasználónevet és jelszavat 
rendelünk, amely csak az IMAP-bejelentkezéshez használható. 
A cikk további részében a helyi és a virtuális fogalmat ilyen 
értelemben fogjuk alkalmazni. 


Áttekintés 

Az 1. ábra bemutatja, hogyan kapcsolódik egymáshoz a Postfix, 
a Courier, a Procmail és az OpenLDAP A helyi azonosítók a 
/etc/password fájlban találhatók, az azonosítást pedig a betölt- 
hető azonosítómodulok (Pluggable Authentication Module, 
azaz a PAM) végzik. A virtuális azonosítók adatait az LDAP 
könyvtárban tároljuk. Az LDAP az azonosítókeresési és -hite- 
lesítési lehetőségeket egyaránt támogatja. Ha szükséges, az 
LDAP könyvtárat ki lehet hagyni, így azonban jóval nehezebb 
lesz karbantartani a virtuális azonosítók adatait. Megfelelő 
beállításfájlokkal mind a Postfix, mind a Courier támogatja 

a virtuális azonosítókat, ezek azonban eltérő formátumúak. 
Az SMIP-ről érkező leveleket a Postfix fogadja. Az ismeretlen 
(helyi vagy virtuális) azonosítóról érkező leveleket elutasítja. 
A virtuális azonosítókhoz maga juttatja el a levelet, a helyi 
felhasználókhoz pedig a Procmailt használja MDA-ként. 

A Courier az IMAP és a POP protokollokon keresztül távoli 
elérést nyújt levélládákhoz. 


A levélláda helye 

A helyi azonosítók leveleit Maildir formátumban a saját könyv- 
tárukban tároljuk, a 5 (HOME ) /Maildir/ alkönyvtár alatt. 
Általánosan alkalmazott megoldás, hogy a Maildir kézbesítését 
a /var/spool/mail helyett az azonosító saját könyvtárába végez- 
zük. Mind a Postfix, mind a Courier tökéletesen működik ezzel 
a szabványos módszerrel. 

A helyi azonosítókkal ellentétben a virtuális azonosítók leve- 
leihez nem tartozik szabványos hely. Ezért külön Unix-azono- 
sítót készítettünk vmai1 néven, ahol az összes virtuális fel- 
használó leveleit elhelyezhetjük. Minden virtuális tartomány- 
hoz tartozik egy alkönyvtár a —vmail/domains/ könyvtárban. 
Például ha van egy Cjohn€épelda.hu: azonosítónk, a levelek 
a —vmail/domains/pelda.hu/john/ könyvtárba kerülnek Maildir 
formátumban. 
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1. ábra Általános kiépítés 


Az LDAP könyvtár megtervezése 

Könyvtárunkat számtalan módon megtervezhetjük, a témát 
most nem elemezzük az összes lehetséges szempont szerint. 
Cikkünkben feltételezzük az LDAP-fogalmak és szaknyelv 
általános ismeretét. 


A faszerkezet 

Gyökérutótagként a cég tartománynevét (myhosting.example) 
választottuk. A Postfix és a Courier egyaránt az 0-hosting, 
dc-myhosting, dc-example alfában keresi majd az elektro- 
nikus levél adatait. Az o-accounts , dec-myhosting, 
dc-example alfa bemutatja, hogyan tudnánk egyetlen könyv- 
tárba beilleszteni a héjprogram-azonosítók PAM-adatait is, ez 
azonban a levelezéshez most nem szükséges. Minden kezelt 
tartomány saját szervezettel rendelkezik a hosting szervezet 
alatt. Minden elektronikus levélazonosító a tartományok 
alfájába kerül. Ennek megfelelően a CuserxXwdomain2.example— 
elektronikus levélcím megkülönböztető neve: 


mail-user20domain2 . example , 0-domain2 . example, 
o0-hosting, dc-myhosting, dc-example 


A fenti tervezet elég megbízható, hiszen az azonosítókat soha 
nem visszük át másik tartomány alá. lervünk emellett 
rugalmas is, hiszen az egyes tartományfákat — amennyiben 
szükséges - tetszés átszabhatjuk. Minden tartományhoz 
tartozik egy postamester-bejegyzés, ami kettős feladatot lát el. 
Elsődleges célja az elérési jogosultságok szabályozása, emellett 
levéltovábbító elektronikus levélcímként is üzemel. Minden 
tartományhoz tartoznia kell egy kitiltandók listájának (abuse 
alias), amely a rendszergazdának továbbítja a leveleket. 


sémaválasztás 

A séma mutatja meg (objektumosztályok megadásával), hogy 
milyen tulajdonságai (attributum) lehetnek egy bejegyzésnek. 
Az OpenLDAP rendszerhez szállított sémák közül egyik sem 
felel meg igazán olyan bejegyzésekhez, amelyeket kizárólag 








elektronikus levelesládákhoz és levéltovábbításhoz szeretnénk 


használni. Ezért inkább a Courier-terjesztésben található sémát 
használjuk fel. Erdemes megnézni a gmail-LDAP Projekttel 
érkező sémát is. 


A Courler-séma 

A virtuálislevél-azonosítókhoz használt courierMailAccount 
objektumosztályt az 1. táblázatban foglaltuk össze. A 2. táblázat- 
ban látható courierMailAlias objektumosztályt azokhoz az 
elektronikus levélcímekhez használjuk, amelyek más címekre 
továbbítanak neveket. 

A courierMailAccount objektumosztály sajnos nem felel 
meg tökéletesen a céljainknak. Az uidNumber és gidNumber 
számunkra felesleges, hiszen minden levelet a vmai 1 azonosí- 
tóra küldünk. Valamilyen álértéket mégis be kell írnunk, mivel 
a séma megköveteli a jelenlétét. Figyeljük meg, hogy ha több 
Unix-azonosító közt osztottuk volna szét a virtuális azonosí- 
tókat, ezeknek az értékeknek is lenne értelmük. Szükségünk 
lesz a levélláda- (mailbox) tulajdonságra, mivel ez alapján tud- 
juk megállapítani a levélláda helyét a fájlrendszeren. A levél- 
láda bejegyzésnek perjellel kell végződnie, így jelezve, hogy 
Maildir stílusú levelesládáról van szó. A userPassword 
kapcsolóra úgyszintén szükségünk lesz, hiszen az elektronikus 
levélazonosítókhoz jelszavakat kell rendelnünk, hogy IMAP- 
vagy POP-rendszeren keresztül elérhetők legyenek. A többi 
elhagyható tulajdonságot nem használjuk. 

A courierMailAlias objektumosztály éppen megfelel 
nekünk. Csak a két kötelező kapcsolót fogjuk használni, az 
elhagyhatók közül egyikkel sem foglalkozunk. A mai ldrop 
tulajdonság egy másik elektronikus levélcím vagy a helyi gép 
egy azonosítója lehet. 


Jogosultságszabályozás 

Az OpenLDAP több lehetőséget is kínál a jogosultság szabá- 
lyozásra. Alapértelmezés szerint a rendszergazdai azonosító- 
nak a fa összes bejegyzésére írási és olvasási joga van. A felü- 
gyeleti feladatok egy részét érdemes kezelendő tartományon- 
ként külön azonosítókra ruházni, hogy a kisebb változtatásokat 
a rendszergazdai azonosító elérése nélkül is elvégezhessék. 

Ezt úgy érhetjük el, hogy azokban a bejegyzésekben, ahol fel- 
ügyeleti előjogokat akarunk adni, a postmaster (postamester) 
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bejegyzést organizationalRole-á tesszük a 
roleOccupant tulajdonsággal. Aztán az OpenLDAP-ot 
beállíthatjuk úgy is, hogy csak e csoport tagjai érhessék el. 


Megvalósítás 

Ebben a részben bemutatjuk, hogyan valósíthatunk meg egy 
virtuális levelezést. Minden apró részletet nem fogunk ismer- 
tetni, csak azokra térünk ki, amelyek a szabványos telepítésen 
felül szükségesek. 

Alább felsoroltuk azokat a programokat (és változatszámokat), 
amelyeken az alkalmazást kipróbáltuk: 

e Red Hat Linux 6.2, 7.1 vagy 7.2; 

e — Postfix 1.1.x; 

e . OpenLDAP 2.0.21; 

e — Courier-IMAP 1.4.1; 

e — Procmail 3.22. 

Létre kell hoznunk a vmai1-azonosítót, majd a —vmail[/ 
domains/ könyvtárat. lovábbá szükségünk lesz még két azono- 
sítóra és két csoportra a Postfixhez — a Postfix telepítési útmu- 
tatójának megfelelően. 

Az OpenLDARP fordításához és telepítéséhez nem lesz szük- 
ségünk különleges ismeretekre, így az utasításokat nézzük meg 
a leírásban. Éles alkalmazás esetén előbb olvassuk el, hogyan 
lehet az OpenLDAP rendszert nem rendszergazdakérnt futtatni 
a chroot-környezet felállításával és másolással. Ebben a 
cikkben azt mutatjuk meg, hogyan kell a slapd-t egyetlen 
kiszolgálón beállítani, létrehozni az alapfaszerkezetet, illetve 
beszúrni néhány alapadatot az LDAP-könyvtárba. 
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A slapd beállítása 

Szükségünk lesz a Courier sémafájlra, ezért a Courier-terjesztés 
authlib/authldap.schema állományát másoljuk a /usr/local/etc/ 
openldap/schemajcourier.schema helyre. A Courier-séma a 
cosine.schema és a nis.schema sémáktól függ. Adjuk a követ- 
kező sorokat a slapd.conf fájlhoz: 


include 

/usr/1ocal/etc/openldap/ schema/cosine . schema 
include 
/usr/1ocal/etc/openldap/schema/nis . schema 
include 

/usr/1ocal/etc/openldap/ schema/courier . schema 


Ezután az adatbázis-meghatározásokat a slapd.conf fájlban 
a következő bejegyzésekkel állítsuk be: 


directory /usr/1local/var/openldap- Ildbm 
database ldbm 
suffix "decmyhosting, dc-example" 


A database kulcsszó meghatározza, hogy milyen háttértárat 
használunk (itt LDBM adatbázist adtunk meg). A directory 
jük, hogy az itt megadott elérési útnak a slapd indítása előtt 
már léteznie kell, és a slapd írási és olvasási jogokkal kell 
rendelkezzen a könyvtáron (és természetesen az sem árt, ha 
execute jogosultsága is van, különben nem fog menni - a 
ford.). A suffix kulcsszó az adatbázishoz rendelt root 
utótagot adja meg. A következő néhány sor a szuperfelhasz- 
nálói, más néven root azonosítót adja meg: 


rootdn 
"cn-Manager , deczmyhosting, dc-example" 
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rootpw 
( SSHAlraOsD4 7OPZ32ASAlaAhF8kgi-8BAf1bgr7 


A rootdn bejegyzésnek korlátlan elérési jogai vannak a teljes 
adatbázis felett, ezért jelszavát a tényleges adatbázison kívül 
őrizzük. A rootpw kulcsszóval megadott jelszót mindig kódolt 
formában tároljuk. Soha ne írjunk be egyszerű szöveget jel- 
szónak. A szöveges jelszó (például: secret) titkosított jelszóvá 
kódolását a slappasswd paranccsal végezzük el: 

s slappasswd 

New password: secret 

Re-enter new password: secret 

( SSHAlraOsD4A 7TOP32ASAlaAhF8kgi-BAf1bgr7 


A kiírt sort vegyük ki a slappasswa-ből és másoljuk a 
slapd.conf fájlba, ahogy a fenti példában is tettük. 

A keresések gyorsítása érdekében az általánosan használt 
tulajdonságokhoz indexeket készíthetünk: 


index 
index 


objectClass 
mail,cn 


pres, eg 
eg, sub 


A slapd.conf utolsó része a jogosultságszabályozás. 


A könyvtárfa létrehozása 

A slapd beállítása után ideje hozzáfognunk az LDAP könyv- 
tár feltöltéséhez. Az OpenLDAP-pal szállított parancssoros 
eszközöket fogjuk használni, és LDIF fájlokat hozunk létre 

a könyvtár módosításához. 

Az első lépés a root csomóponthoz tartozó alapszerkezet 
elkészítése: ez az otthont adó szervezet (hosting organization) 
és a rootdn-hez tartozó bejegyzés. Hozzunk létre egy fájlt 
base.ldif néven a következő tartalommal: 

dn: dc-myhosting, dc-example 
objectClass: top 
dn: cn-Manager, dc-myhosting, dc-example 
objectClass: top 

objectClass: organizationalkRole 

cn: Manager 

dn: o0-hosting, dc-myhosting, dc-example 
objectClass: top 

objectClass: organization 

o: hosting 


Használjuk az Idapadd parancsot a rendszergazdai azonosítót 
használva, hogy bevigyük a fenti LDIF-et: 


ldapadd -x -D 
"cn-Manager , dez-myhosting, dccexample "NM 
-w secret -f base.ldif 


Tartomány felvitele 

Immár felvihetjük a tartományokat a , hosting" fa alá. Minden 
tartománynak rendelkeznie kell legalább a postamesterrel és 
a kitiltandók listája bejegyzésekkel (abuse entries). 

A domain1.example fa létrehozásához készítsünk egy 
domain1.example.ldif nevű fájlt a következő tartalommal: 


dn: o0-domainl.example, 0o0-hosting, 
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dceccmyhosting, 

dc-example 
objectClass: top 
objectClass: organization 
o: domainlil.example 
dn: cn-postmaster, o-domaini.example, 
özshostina, 


deccmyhosting, dc-example 


objectClass: top 
objectClass: organizationalkRole 
objectClass: CourierMailAlias 


cn: postmaster 
mail: postmasterOodomainili.example 
maildrop: postmaster 


dn: mail-abuseodomaini.example, 
o0-domaini . example, 

öshosting, deszmyhosting, 
objectClass: top 
objectClass: CourierMailAlias 
mail: abuseodomaini.example 
maildrop: abuse 


dc-example 


Figyeljük meg, hogy a mai ldrop kapcsolók mindig helyi elekt- 
ronikus levélazonosítók, és a postamesterhez, illetve a /etc/ 
aliases fájlban megadott álnevekre továbbítódnak. A postmaster 
szabályban nem adtunk meg azonosítót, így jelenleg kizárólag 
a rendszergazdai azonosítón keresztül lehet új azonosítókat 
létrehozni. Vigyük fel a tartományt a következő paranccsal: 


ldapadd -x -D 
"cn-Manager , dec-myhosting, dc-example tő N 
—m-w secret  -f domainlil.example.ldif 


Azonosítók felvitele 

Vigyük fel a cuserI(wdomainl.example: levélcímmel rendel- 
kező felhasználót. Egyúttal ennek a felhasználónak adjunk pos- 
tamester-előjogokat a domain1.example tartományra. Készítsük el 
a user1l.domain1.example.ldif fájlt a következő tartalommal: 


dn: mail-userlodomaini.example, 

o0-domaini . example, 
oshosting, dceszmyhosting, 

objectClass: top 

objectClass: CourierMailAccount 

mail: userlodomaini.example 

homeDirectory: /home/vmail/domains 

uidNumber: 101 

gidNumber: 101 

mailbox: domaini1.example/useri 
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dn: cn-postmaster, o-domaini!i.example, 

öshosting,; 

dceccmyhosting, dc-example 

changetype: modify 

add: roleOccupant 

roleOccupant: mail-userlodomaini.example, 
o0-domaini.example, o-hosting, 
dcc-myhosting, dc-example 


Az első rész az azonosítóhoz tartozó bejegyzést viszi be. 
A home directory és a mailbox a fájlrendszeren fizikailag 


elérhető levelesládára mutat. Az uidNumber és gidNumber 
kapcsolók kötelezően megadandók, de mivel mi nem használ- 
juk őket, a 101-es próbaértékkel (dummy value) töltöttük fel. 

A második rész módosítja a postmaster bejegyzést — hozzáadja 
a roleOccupant kapcsolót a user1odomain1 . example 
DN-t használva. Hozzuk létre ezt a bejegyzést: 


ldapadd -x -D 
"cn-Manager , dec-myhosting, dc-example" 
.-w secret -f useri.domaini.example.ldif 


Mivel az azonosítóhoz még nem tartozik jelszó, hiába rendel- 
kezik postamesteri jogosultságokkal, nem tudjuk hitelesíteni. 
Az Idappasswd paranccsal állítsuk be a user1 kezdeti 
jelszavát: 


ldappasswd -x -D "SDN" -w SPW -s useri1 
5!"!mail-userlOodomaini.example, 
o0-domaini . example, 
o-hosting, dc-myhosting, dc-example" 

A további tartományokat és azonosítókat hasonló LDIF fájlok- 
kal vihetjük fel. Az LDIF fájlok felvitele kézi módszerrel meg- 
lehetősen fárasztó, ráadásul könnyen hibázhatunk is. Később 
más módszereket is mutatunk a felügyeletre. 


Postfix 


A Postfix rendszernek csak azokat a részeit tárgyaljuk, amelyek 
a levélkezelésre vonatkoznak. 

Töltsük le a Postfix-forrást és csomagoljuk ki. Újra kell építe- 
nünk a Postfix Makefile-okat, hogy figyelembe vegyék és 
hivatkozzanak (link) az LDAP programkönyvtárakra. Hajtsuk 
végre a következő parancsot: 


make makefiles CCARGS-"-I/usr/local/include 
-DHAS LDAP" AUXLIBS-"-L/usr/local/lib - I Idap 
mp T,/usr/1local/lib -1lber" 


Innentől követhetjük a szokásos Postfix fordítási és telepítési 
útmutatásokat, amelyeket az INSTIALL és az LDAP README 
fájlokban találunk. 


A Postfix beállítása 

Ha az alább bemutatott beállítási példák bármelyikéhez nem 
neveztünk meg kifejezetten valamilyen fájlt, akkor azt minden 
bizonnyal a main.cf fájlban találjuk. 

A szállítási tábla (transport table) a tartományokat rendeli az 
(/etc/postfix/master.cf fájlban megadott) üzenetkézbesítő egysé- 
gekhez (message delivery transports), illetve a továbbító gaz- 
dagépekhez. Mi virtuális tartományainkat a Postfixszel érkező 
virtuális kézbesítő ügynököknek szeretnénk átadni. A szállítási 
tábla tehát valahogy így néz ki: 


virtual : 
virtual : 


domain!1 . example 
domain2 . example 


Miután egyszerű szövegfájlként elkészítettük a szállítási táblát, 

a postmap utasítással (lásd man postmap) át kell alakítanunk 
bináris DB állománnyá. Ha ezzel megvagyunk, mutassuk meg a 
Postfix rendszernek, hogy van egy szállítási táblánk, és hogy azt 
merre találhatja meg. Azt is tudatnunk kell a Postfix programmal, 
hogy ezekre a tartományokra leveleket várunk. 
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Ezt a transport maps és mydestination kulcsszavakkal 
tehetjük meg: 


transport maps - hash:/etc/postfix/transport 
smydestination - Smyhostname, 

s localhost . Smydomain, 

s — Smydomain, S$transport maps 


Könnyen megadhatunk többszörös LDAP-forrásokat is. Az LDAP- 
forráskapcsolók leírását a README FILES/LDAP README 
fájlban olvashatjuk, a Postfix forrásában. A kapcsolónevek 
cldapforrEsz kapcsol alakúak. Az LDAP-forrás nevét a 
használatával adjuk meg. A main.cf fájlban keresésenként egy- 
egy LDAP forrásmeghatározásra lesz szükségünk. 


Alnevek 
Az első LDAP-forrásmeghatározást a virtuális álnevekhez hoz- 
zuk létre. Ezt az LDAP-forrást , aliases"-nek, azaz álneveknek 
neveztük el. Beállításunk szerint az LDAP-kiszolgáló a helyi 
gépen fut. A keresés alapja az LDAP-kiszolgálónkon megadott 
,hosting" alfa lesz. Azokat az elemeket kérjük le, ahol a mail 
elem megegyezik a levél címzettjével, illetve amelyek a 
courierMailAlias objektumosztályba tartoznak. Az álnév- 
hez rendelt célszemélyt a mai ldrop tulajdonsága tartalmazza. 
A Postfix nem fog felhasználóként bejelentkezni, hanem 
anonim keresést végez: 
aliases server host - localhost 
aliases search base - 

o0-hosting, dec-myhosting, dc-example 
aliáses güery filter : 

(6((mail-$s) (objectClass-CourierMailAlias) ) 
aliases result attribute - maildrop 
aliases bind - no 


Azonosítók 
Amikor az accounts (azonosítók) forrást használjuk, olyan 
bejegyzéseket keresünk, amelyek a courierMailAccount 
objektumosztályba tartoznak. Eredményként a mailbox tulaj- 
donságot kérjük vissza: 
accounts server host z locaihost 
accounts search base - 

o0-hosting, dec-myhosting, dc-example 
accounts guüétry filter s 

(6((mail-$s) (objectClass-CourierMailAccount) ) 
accounts result attribute — mailbox 
áccoünts bind - nö 


Az azonosítókhoz egy második, accountsmap nevű forrást is 
létre kell hoznunk, hogy az azonosítókat catchal11 (minden 
elem megvizsgálása) esetén is le tudjuk kérni. Enélkül az 
álnevekben használt catcha11 felülbírálná a tartományok 
virtuális azonosítóit: 
accoüntsmap setver host zs localhost 
accountsmap search base - 

o0-hosting, dec-myhosting, dc-example 
aáaccountsmap güery filter s 

(6(mail-$s) (objectClass-CourierMailAccount 
accountsmap result attribute - mail 
accountsmap bind - no 
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Miután megadtuk az aliases és az accountsmap LDAP- 
forrásokat, tudassuk a változtatásokat a Postfix programmal, 
és állítsuk be amain.cf virtual maps kapcsolóját: 
virtual maps - ldap:aliases 

A példa kedvéért tételezzük fel, hogy már készítettünk egy 


vmail nevű Unix-azonosítót, amely a 125-ös UID, és a 120-as 
GID értékeket birtokolja, a saját könyvtára pedig a /home/omail: 


/home/vmail/domains 
ldap : accounts 


:virtual mailbox base - 
virtual mailbox maps - 


virtual minimum uid - 125 
virtuál üld maps zs Sstatic:125 
virtual gid maps - static:120 


A virtual uid mapsés virtual gid maps értékeit egy 
különleges statikus térképhez rendeltük, belekódolva a vmai1 
azonosító UID és GID értékeit. Az összes itt bemutatott kap- 
csoló teljes leírását elolvashatjuk a Postfix forrásával együtt 
kapott README FILES/VIRTUAL README állományban. 

Át kell szerkesztenünk a local recipient maps kapcsolót, 
hogya virtual mailbox maps-ban keresgéljen, így a 
Postfix tudni fogja, hogy mely azonosítók érvényesek. Ez azért 
szükséges, mert a Postfix el tudja utasítani az ismeretlen azo- 
nosítókra érkező leveleket: 


local recipient maps - $Salias maps 
unix :passwd.byname $virtual mailbox maps 


Courier 

Semmilyen különleges utasítást nem kell használnunk a Cou- 
rier telepítéséhez, úgyhogy útmutatásért forduljunk nyugod- 
tan a leíráshoz. Meg fogja találni és be fogja fordítani az LDAP- 
ot. Érdemes meggondolni a --enable-workarounds-for- 
imap-client-bugs kapcsoló használatát a . /configure 
futtatásakor, mert enélkül a Netscape-felhasználóknak gondjaik 
támadhatnak, amikor a kiszolgálónkat akarják használni. 

A Courier külön azonosítódémont használ, hogy az azonosítást 
elválassza a rendszer egyéb részeitől. Állítsuk be úgy, hogy az 
érvényes levélazonosítókat LDAP és PAM alatt is megtalálja. 
Ezt az authdaemonrc fájlban az authmodulelist kapcsolóval 
adhatjuk meg: 


authmodulelist-"authildap authpam" 


Minden LDAP-kapcsoló az authldaprc-ben található. A leg- 
több kapcsoló magától értetődő. A Courier-séma használatához 
azonban el kell végeznünk néhány változtatást. Ezenkívül az 
összes virtuális azonosítót a vmai 1 azonosítóhoz kell rendel- 
nünk. Összefoglalóan a következő változtatásokat kell elvé- 
geznünk az authldaprce-ben: 


LDAP GLOB UID vmail 

LDAP GLOB GID vmail 

LDAP HOMEDIR homeDirectory 
LDAP MAILLDIR mailbox 

LDAP CRYPTPW üserPassword 


Három további beállítás alkalmazását érdemes megfontolnunk, 
ezek: a LDAP AUTHBIND, a LDAP BINDDN és az LDAP BINDPW 
- mindhárom a felhasználó azonosításához tartozik. Az LDAP 
AUTHBIND kulcsszó és a LDAP BINDDN, LDAP BINDPW páros 
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kölcsönösen kizárja egymást. Mi az LDAP AUTHBIND használatát 
javasoljuk. Az authldaprc egyik megjegyzése memóriaszívást 
említ az OpenLDAP-ban a LDAP AUTHBIND használatakor, ezt 
azonban az OpenLDAP 2.0.19 változatában már kijavították. 

Ha az LDAP BINDDN és LDAP BINDPW kulcsszavakat hasz- 
náljuk, jelszavainkat csak a crypt, MD5 és SHA algoritmusokkal 
kódolhatjuk. Az SMD5 és az SSHA nem lesz elérhető. lovábbá 
ha LDAP BINDPW adunk meg, az LDAP jelszó egyszerű szöveg- 
ként kerül az authldaprc fájlba. Az LDAP-jelszavakat egy- 
szerű szövegként tárolni komoly biztonsági rést jelent, így ha 
csak lehet, inkább az LDAP AUTHBIND módszert használjuk. 

Az utolsó változtatás, amit el kell végeznünk, az IMAP-kiszolgáló 
beindítása az IMAPDSTART kapcsoló YES-re történő állításával. 
Mostantól a courier-imap. sysvinit indító parancsfájlt 
használhatjuk az IMAP-démon indításához és leállításához. 


Felügyelet 

A legtöbb felügyeleti feladat, az azonosítók és álnevek felvétele, 
módosítása és törlése az LDAP könyvtár módosítását igényli. 
Ezt az OpenLDAP parancssoros eszköz segítségével vagy 
valamilyen általános LDAP böngésző (például a gg) alkalma- 
zásával tehetjük meg. Jelenleg egy Jamm nevű webfelügyeleti 
alkalmazáson dolgozunk, amely lényegében egy Java és JSP 
nyelven íródott alkalmazásspecifikus LDAP-böngésző lesz. 
Saját LDAP-sémával is rendelkezik, amely tulajdonképpen egy 
kis mértékben módosított Courier-séma. A Jamm jelenleg 

is használható és folyamatosan fejlődik — a legfrissebb tájékoz- 
tatást a Jamm SourceForge honlapon találjuk. 


Megjegyzések az azonosítókészítéshez 

Amikor azonosítókat és álneveket készítünk, az LDAP adatbá- 
zisban azok azonnal működővé válnak - feltételezve, hogy a 
levelezőrendszer ezen felhasználja őket. A virtuális azonosítók 
létrehozásakor ne feledjük, hogy a hozzájuk tartozó Unix- 
könyvtár nem jön létre a -vmai1-ben. Ezt azonban orvosol- 
hatjuk, mivel a Postfix virtuális kézbesítőügynöke az első levél 
megérkezésekor létrehozza a szükséges könyvtárakat. Éppen 
ezért azt javasoljuk, hogy amint létrehoztuk az azonosítót, 
küldjünk egy üdvözlőlevelet. 
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Kisérletezgetés a Ptrace-szel (2. rész) 


Sorozatunk második részében Pradeep néhány komolyabb témát boncolgat: 
a töréspontok beállítását, illetve kód beszúrását a már futó folyamatokba. 


orozatunk első részében (Linuxvilág 2003. január) lát- 
§ hattuk, hogyan lehet a Ptrace felhasználásával követni 

a rendszerhívásokat, illetve megváltoztatni a rendszer- 
hívások jellemzőit. Most olyan összetettebb módszereket ismer- 
hetünk meg, mint a töréspontok beállítása vagy a kódnak futó 
programokba történő beillesztése. A hibakeresők ezeket a mód- 
szereket töréspontok beállítására és hibakereső-kezelők futtatá- 


sára használhatják. Akárcsak az előző részben, a mostani írá- 
sunkban található valamennyi kód is 1386 architektúrára épül. 





Csatlakozás a futó folyamatokhoz 

Az első részben a követendő folyamatot gyermekként futtat- 
tuk aptrace(PTRACE TRACEME, . . ) hívás után. Amennyi- 
ben csak arra vagyunk kíváncsiak, hogyan ad ki a program 
rendszerhívásokat, ez elegendő is. Ha azonban már futó 
folyamatot szeretnénk követni vagy elemezni, inkább a 
ptrace(PTRACE ATTACH, ..) hívást használjuk. 

Ha a ptrace(PTRACE ATTACH, . .) függvénynek a köve- 
tendő folyamatazonosítót (pidet) átadjuk, megközelítőleg 
azonos hatást érünk el, mintha a folyamat a 
ptrace(PTRACE TRACEME, . .) hívást használná és a 
nyomkövető folyamat gyermekévé válna. A követett folyamat 
SIGSTOP üzenetet kap, így a szokásos módon megvizsgálhat- 
juk vagy módosíthatjuk. Miután végeztünk a módosítással 
vagy követéssel, a követett folyamatot a 

ptrace(PTRACE DETACH, . .) hívással az útjára 
engedhetjük. 

A következő kód egy kis követőprogramra mutat példát: 


int main() 
( TIME. As 
forii s 0-1 é 107 441) ( 
printf ("SzEmlEl adat. 49 
sleep (2) ; 
! 
return 0; 


] 


Mentsük a programot dummy2.c néven. Fordítsuk le és 
futtassuk: 


gcc -o dummy2 dummy2.c 
./dummy2 § 


Ezekután az alábbi kód segítségével tudunk csatlakozni 
a dummy2-höz: 


csys/ptrace.hs: 
csys/types.hs 
csys/wait.h: 

Hinclude caunistd.h: 

Hinclude c-linux/user.hsz 

/: Az user regs struct-hoz stb. §/ 


Hinclude 
Hinclude 
Hinclude 
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int máinlint aga, char targyiíl] 
( pid t traced process; 
struct user regs struct regsSs; 


long ins; 
if(argc 1- 2) ( 
printf("Hasznglat: §s ck vetendi 
states vi , 
argv[I0O01, argv[1]) ; 


exit (1); 


] 


tracéd process z atóilargvyil] ); 
ptrace(PTRACE ATTACH, traced process, 
5NULL, NULL) ; 
wait (NULL) ; 
ptrace(PTRACE GETREGS, 
5NULL, §regsS) ; 
ptrace(PTRACE PEEKTEXT, 
traced prócesS, 
regs.eip, NULL) ; 
printf("EIP: $1x vOgrehajtott utas tE£s: 
mslxwn", regs.eip, ins); 
ptrace(PTRACE DETACH, traced process, 
SNUDL; NÜLL) ; 


traced PErOCSSE ; 


ins - 


return 0; 


] 


A fenti program egyszerűen csatlakozik a folyamathoz, 
megvárja, amíg megáll, megvizsgálja az eip (utasításszámláló) 
tartalmát, majd leválik. 

A követett folyamat megállása után a ptrace 

(PTRACE POKETEXT, ..) ésa ptrace(PTRACE POKEDATA, 
. . ) függvényt használhatjuk kódbeillesztéshez. 


Töréspontok heállítása 

Hogyan állítanak be a hibakeresők töréspontokat? Általában 
a végrehajtandó utasítást egy csapdautasításra cserélik le, így 
amikor a követett program megáll, a követőprogram (azaz a 
hibakereső) nyugodtan vizsgálódhat. Amikor aztán a követő- 
program folytatni akarja a követett kódot, egyszerűen vissza- 
helyettesíti az eredeti utasítást. Íme egy példa: 


Hinclude 
Hinclude 
Hinclude 


csys/ptrace.hs 
csys/types.hs: 

csySs/wait.h: 

Hinclude caunistd.hsz 

Hinclude c-linux/user.hsz 

dönst 10 long Ss126.  S1zEé0fl long) ; 


void getdatalpid t child, long addtf; 
schar "str, int len) 
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] 


void pütdataípid € ehild, 


( 


] 


int main(int argc, 


( 
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char F"laddr; 
at 1a Ti 
üntön ü. 1 
long val; 
char charsilong sizel; 
data; 


1 — 0: 
j - len / long size; 
laddr - str; 
while(i c j) ( 
data.val - ptrace(PTRACE PEEKDATA, 


sschild, addr 4 
—m]i xx 4, NULL) ; 
memcpy(laddr, data.chars, long size); 
H-Hi; 
laddr -4- long size; 
J 
j e len S lóng Síiz8; 
if(j !- 0) ( 
data.val - ptrace(PTRACE PEEKDATA, 
sschild, addr 


ri xl4, 
data.chars, Jj); 


NULL) ; 
memcpy (laddr, 


] 


strIlen] - 


0 


long addr, 
char "str, int len) 
char tladdr; 
int. íz J? 
union u ( 
lonéd val; 
char charsllong sizel; 
data; 
1 s 0; 
j - len / long size; 
laddt sz SÜT; 
while(i c j) ( 
memcpy (data. chars, 
ptrace(PTIRACE POKEDATA, 


laddr, long size); 
ehü ld; 


saddr 4t i XX 4, data.val) ; 
4-1; 
laddr -4- long size; 
] 
j s len S leng Size; 
iríj ls 0) 1 
memcpy (data.chars, laddr, j); 
ptrace(PTRACE POKEDATA, child, 
saddr tt i XX 4, data.val) ; 


char rargv[(]) 
pid € traced pr-OCéSS; 

struct user regs struct regs, 
long ins; 

/r int Ox8O, int3 F/ 

char code[] - (0Oxcd, 0x80, O0xcc, 0); 
char backup [4] ; 


newregs ; 
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] 


if(argc 1- 2) ( 
printf("Hasznkglat: $s ck vetendi 
szotdsat, argvlól; arovili1); 
exit (1) ; 
] 
traced process z atoilargyiil]; 


ptrace(PTRACE ATTACH, traced process, 
NULL, NULL) ; 
wait (NULL) ; 


ptrace(PTRACE GETREGS, 
5SNULL, 6regS) ; 


traced prOCESS; 


/: Utas tEs mEsolZsa ideiglenes tErol bar/ 
gétdataltraáced process, Trégs. 810, 
aspaáckup, 3) 7 


/: T röspont elhelyezgse "/ 
pütdata (traced process, fegs.€1p,. Code, 3] 


/:" Engedj k tovEbb a folyamatot Os vErjuk 

meg, am g vögrehajtja az int 3 utas tEst F/ 

ptrace(PIRACE CONT, traced process, NULL, 
5SNULL) ; 


wait (NULL) ; 
printf("A folyamat legllt, visszarakjuk 
az eredeti utas tAgsokatm!") ; 
printf ("Folyatat£gshoz nyomja le az 
5 acenters billentyiíitm!") ; 
getchatr ( ) ; 
putdata (traced process, regs.eip, backup, 3); 


/F Az eip-t visszaEl1 tjuk az eredeti 
utas tEsra, hogy a folyamat tovXgbb 
futhasson F/ 
ptrace(PTRACE SETREGS, 
5NULL, 6§regsS) ; 


traced pPEOGCÉSS; 


ptrace(PTRACE DETACH, traced process, 
sSNUGIr, NULL) ; 
retürn.  Ú; 


Az előbb tehát három bájtot a csapdautasítás kódjával helyet- 
tesítettünk, majd amikor a folyamat megállt, az eredeti utasítást 
visszahelyettesítettük, azután az eredeti helyére állítottuk 
vissza az eip-t. Az 1-1. ábra segít megérteni, hogyan néz ki 

az utasításfolyam a fenti program végrehajtásakor. 

Most, hogy már tisztáztuk a töréspont-beillesztés módszerének 
a hátterét, szúrjunk be pár kódbájtot a futó programba. A kód- 
bájtok a , hello world" üzenetet fogják megjeleníteni. 
Következő programunk csak egy egyszerű, de az igényeinkhez 
igazított , hello world" program lesz. A programot a következő 
paranccsal fordítsuk le: 


gödi 


-o hello hello.c 


void main() 


( 


. asm (" 


jmp forward 


backward: 
pópi $esi H A hello world sz veg 
H c mönek lekörgse 
mov1 S4, S$eax Ht "rEsi rendszerh vEs 
H köröse 
mov1l 52, Ssebx 
mov1l Sesi, $ecx 
mov1l 512, S$edx 
int S0x80 
1at3 H 1 rÖspont. Itt a 
H program meggl1l, 
H Os a vezőrigst 
H visszaadja 
t a sz linek 
forward: 
call backward 


.string W"Hello Worldtán tt 
a 
I 


Az előre-hátra (forward/backward címekre) ugrálásra azért 
van szükségünk, hogy a , hello world" szöveg címét 
megállapíthassuk. 

A fenti assemblyhez tartozó gépi kódot lekérhetjük a GDB-ből. 
Indítsuk be a GDB-t, és fejtsük vissza a programot: 


(gdb) disassemble main 

Dump of assembler code for function main: 
0x80483e€0 -main;: push  S§ebp 

0x80483e1 -maini1l:: mov sesp, 5ebp 

0x80483e€3 -maint435: jmp 0x80483fa c-forw ard: 
End of assembler dump. 

(gdb) disassemble forward 

Dump of assembler code for function forward: 


0x80483fa cforwardz: : call 0x80483e5 
cbackward: 

0x80483£f -cfiorwardi553: dec 5eax 
0x8048400 c-forward-66-: gs 

0x8048401 cforwardrt7:: insb 
(sdx) , ses: (Sedi) 

0x8048402 c-forward-t8-: insb 
(sdx) , ses: (Sedi) 

0x8048403 c-forwardi95: outsli 

Sds: ($esi) , ( 5dx) 

0x8048404 c-cforwardi10z5: and 

sd1, 0xéf(5edi) 

0x8048407 cforw ard413:: jb 0x8048475 
0x8048409 c-cforwardi155: or 
SÍfs: ( seax) , sal 

0x804840c€c c-cforward-i18:- : mov sebp, sesp 
0x804840€ c-cforw ard-6t20-: pop sebp 
0x804840f cforward-i-215: ret 


End of assembler dump. 


(gdb) disassemble backward 

Dump of assembler code for function backward: 
0x80483e€e5 cbackward;:: pop sesi 
0x80483e€e6 -backward-1:: mov S0x4 , seax 
0x80483eb -backward-t6-: mov S0x2, sebx 
0x80483f£0 -backwardt1i1l:s: mov sesi, secx 
0x80483£2 -backward-t13-: mov S0xc , sedx 
0x80483£7 -backward-i18-: 11 S0x80 
0x80483£9 -backward-6t205: int3 


End of assembler dump. 
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hájt 2 





1. ábra 
Miután a folyamat megállt 


2. ábra Miután a csapda- 
utasításbájtokat elhelyeztük 


nNNNEEF-EEEEETE/ 





4. ábra Az eredeti utasítások 
visszahelyettesítése után az eip-t 
az eredeti helyre állítjuk vissza 


3. ábra A csapda működésbe 
lépett, és a vezérlés a 
nyomkövető programhoz került 


Nekünk a main--3-tól a backward--20-ig van szükségünk a 
kódra, ami összesen 41 bájtot jelent. A gépi kódot GDB alatt 
az x paranccsal jeleníthetjük meg: 


gdb x/40bx main--3 
cmaint35: eb 15 
cbackward-i65:: bb 02 
czbackward-i- 14: : 
cforw ardrt1:5: e6 ff 
cforw ardt935: 6£ 20 


5e b8 04 00 00 00 
00 00 00 89 f1 ba 
0c 00 00 00 cd 80 cc 
ff ff 48 65 6c 6c 
57 6f£ 72 6c 64 0a 


Megszereztük a végrehajtandó utasítások bájtjait. Mire várunk 
akkor? Az előző példában látott módszerrel be tudjuk illeszteni 
őket a futó programba. A forráskód a következőképpen néz ki 


(most csak a main függvényt adjuk meg): 


int main(int argc, char stargvl[]) 
( pid t traced process; 

strucc üser. reds. Sttüet TEégB; 

leng 1n8; 

int len - 41; 

char insertcodel] - 
mxebxi5tx5etxb8BNxO4NKO0OT 


newregs; 


TT KOONOONDDONYOZNYOONYOO NON XB89 NÉL Nba " 
"TT XKOCNOONYOONOO NABOO cc S NÉL T 
"xx vxaBx6ő5NxXx6eNx6ENXSBÉNXZONXK5B7TNX6GÉ" 


" x72R6CNX6ANRKOGNXOOT ; 
char backupllenil ; 


2003. március 43 


e KEZELT 


0 Kiskapu Kft. Minden jog fenntartva 


SZET 


0 Kiskapu Kft. Minden jog fenntartva 


1. lista 
map start-mapend protection offset device inode process file 
08048000-0804d000 Mata 0 G0(000000 03 2 08 (SLCSTALSALATÓ /opt/kde2/bin/kdeinit 
if(argc !- 2) ( fp - fopen(filename, "r"); 
printf("Hasznglat: $s c-ck vetendi 1t(£p sz NULL) 
eegrdsti exit (1) ; 
argvIlO0l; argvIlII); while(fgets(line, 85, fp) !- NULL) ( 
exit (1) ; sscanf(line, "31x-$rlx S$trs 8rs Ss", 
) szaddr, ety, ett, str, str): 
traced procéss zs. átollargyl 1] ) ; í1£.1etrempistrtr, VO0O:O0OV) sz 0] 
ptrace(PTRACE ATTACH, traced process, break; 
5NULL, NULL) ; ) 
wait (NULL) ; fclose(fp) ; 
ptrace(PTRACE GETREGS, traced process, return addr; 
NULL, E§regsS) ; ; 
getdataltraced process, rTregs.eip, backup, 
—m]en) ; A /proc/pid/maps minden sora a folyamat egy-egy lefoglalt 
tartományának felel meg. 
putdata(traced process, regs.eip, A /proc/pid/maps bejegyzést az 1. listában láthatjuk. 
sinsertcode, len) ; 
ptrace(PTRACE SETREGS, traced process, A következő program a kódot az üres területre szúrja be. 
SNULL, EregsS) ; A szerkezete hasonlít az előző beszúróprogramhoz, de azzal 


pbtráce(PTRACE CONT, traceéd. prOCÉSS, 
SNULL, NULL) ; 


wait (NULL) ; 
printf("Ihe process stopped, Putting back 
the original instructions ni") ; 


putdataltraced process, regs.eip, backup, 
s9]1en) ; 

ptrace(PTRACE SETREGS, traced process, 
5NULL, 6§regS) ; 


printf("Letting it continue with 
sagriginal flowyn") 

ptrace(PIRACE DETACH, traced process, 
S5NULL, NULL) ; 

return 0; 


] 


Kód beszúrása szabad helyekre 


Lf at 


Az előző példában a kódot közvetlenül a végrehajtott utasí- 


tásfolyamba szúrtuk be. Sajnos az ilyesmi könnyen össze- 
zavarhatja a hibakeresőket, ezért keressünk inkább egy üres 
helyet a folyamatban, és ide helyezzük a kódot. Az üres 
helyet a követett folyamathoz tartozó /proc/pid/maps fájl 
vizsgálatával találhatjuk meg. A következő függvény e térkép 
indulócímét keresi ki: 


long freespaceaddr(pid t pid) 
( 

FILE rfp; 

char filename [301] ; 

char line[85] ; 

long addr; 

char strl[20] ; 


sprintf(filename, "/proc/$d/maps", pid) ; 
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az eltéréssel, hogy az új kódunk tárolásához az üres terület 
címét használjuk majd fel. A main függvény forrását az aláb- 
biakban olvashatjuk: 


int main(int argc, char targv[]) 
( pid t traced process; 
estruct usert regső etruct oldrégs; 
long ins; 
int len - 41; 
char insertcodel[] - 
"tt xebvxi5tx5etxb8 NXO4NXOOT 


regs; 


TM XOONXOONXDDNXOZNKOONXOONXOONXxB9Nxflvxba" 
"xXOCAXOONXOONXKOO Nr edtx8BONxcetxeB kes XL" 


"Mt xtftxtftkxKABNXSGSNXSGENKSGGNXKGÉNKZONKSTAKSÉT 


nt xx 72 Noe NkK6GANxOGNXOOT ; 
char backupllenil ; 
long addr; 
ir(aego le 2) 1 

printf("Hasznglat: $s ck vetendi 

ség rds iv , 
argv]ól, argylil) ; 

exit (1) ; 
] 
ttacéd procesS§ zs atollargvil] ) ; 


ptrace(PTRACE ATTACH, traced process, 
s NULL; NULL) ; 
wait (NULL) ; 


ptrace(PTRACE GETREGS, traced process, 


S5NULL, §regsS) ; 


addr z Íreéspácsaddr (traced procésS8) ; 

getdata (traced process, addr, backup, len); 

pütdatáltraced process, addr, insertcode, 
mm ]en) ; 

memcpy (soldregs, §regs, sizeof(regs) ) ; 

regs.eip - addr; 

ptrace(PTRACE SETREGS, traced process, 
5S5NULL, §regS) ; 

ptrace(PIRACE CONT, traced process, 
5SNULL, NULL) ; 

wait (NULL) ; 

printf("A folyamat megZllt, 
syvisszahelyezz k az eredeti 
utas tEsokat.n") ; 

puútdata (traced. procéss, addr, bácküp; len); 

ptrace(PTRACE SETREGS, traced process, 
NULL, 6§Oldregs,) ; 

printf ("TovEbbengedj k az eredeti 
STOlyamotA) ; 


ptrace(PTRACE DETACH, traced process, 
NULL, NULL) ; 
FECUTM Új 


] 


A színfalak mögött 

De valójában mi történik ezalatt a rendszermagban? 

Hogyan működik a Ptrace? Ez a rész önmagában megérne 
egy külön cikket — mégis, nézzük meg röviden, hogyan 
zajlanak a dolgok! 

Amikor a folyamat PTRACE TRACEME-mel hívja meg a Ptrace-t, 
a rendszermag beállítja a folyamatzászlókat, hogy jelezze, 

a folyamat követés alatt áll: 


Source: arch/i386/kernel/ptrace.c 
if (reguest -- PIRACE TRACEME) ( 


/: mEr k vetnek minketai F/ 
i£ leürrent-sptrace §€ PT PTRACED) 
götő DÚL; 


/F Ell tsuk be a ptrace bitet 
a folyamatzE£Eszl kban. "/ 
current-sptrace ]- PT PTRACED; 
rét : 0 
goto out; 


] 


Amikor a rendszerhívás-bejegyzés véget ér, a rendszermag 
megvizsgálja a zászlót, és amennyiben a folyamatot követik, 
meghívja a követő rendszerhívást. A nyers assembly- 
részeleteket itt találhatjuk meg: arch/1386/kernel/entry.S. 








Beléptünk a sys trace() függvénybe, ezt a 
arch[/i386/kernel/ptrace.c-ben találhatjuk. A függvény megállítja 
a gyerekfolyamatot, és jelet küld a szülőnek, értesítve őt arról, 
hogy a gyermeket megállította. Az alvó szülő így felébred, és 
végrehajthatja a Ptrace-varázslatokat. Amint a szülő végzett, 

és meghívja aptrace(PTRACE CONT, ..) vagy a 
ptrace(PTRACE SYSCALL, . .) függvényt, a 

wake up process () ütemező függvény meghívásával a 
gyermeket is felébreszti. Más architektúrák ezt úgy oldják meg, 
hogy SIGCHLD üzenetet küldenek a gyereknek. 


Összegzés 

A Ptrace néhány ember számára varázslatos tudománynak 
tűnhet, hiszen képes egy futó program vizsgálatára és követé- 
sére. Általában hibakeresők és rendszerhíváskövető programok 
(például a Ptrace) használják ezt a lehetőséget, ugyanakkor 
érdekes távlatot nyit meg egy felhasználómódú kiterjesztés 
létrehozására is. Számos próbálkozás napvilágot látott már, 

ami az operációs rendszert felhasználószinten próbálja meg 


s a 


bővíteni. A Kapcsolódó címek között olvashatunk az UFO-ról, 
azaz a felhasználószintű fájlrendszerbővítésről (User-level 
extension to Filesystems). A Ptrace-t ezenkívül biztonsági rend- 
szerek megvalósítására is fel szokták használni. 

A cikkben (a jelenlegi és az előző részben) található összes kód 
(eredeti angol változata) tar-állományként elérhető a Linux 
Journal FIP lapján 


[ítp.ssc.com/pubd/lj/listings/issue104/6210.tgz]. 


Linux Journal 2002. december, 104. szám 


Pradeep Padala (p padalaígyahoo.com) 

Jelenleg a Floridai Egyetemen diplomája megszer- 
zésén munkálkodik. Érdeklődési területei között 

a rácsos kiépítésű és osztott rendszerek szerepel- 
nek. Honlapját a 3 http://Awww.cise.ufl. 
edu/-ppadala címen lehet elérni. 





Extending the Operating System at USser Level: 
Ihe UFO Global File System 
2 http:/Avww.cs.ucsb.edu/projects/ufo/9 7-usenix-ufo.ps 


A Ptrace-kézikönyv (Secure, User-Level Resource- 

Constrained Sandboxing) 

a) http://csdocs.cs.nyu.edu/Dienst/Repository/2.0/Body/ 
ncstrl.nyu cs9o2fTR1999-795/pdf 


A Ptrace súgóoldala 
2 http:/Avww.die.net/doc/linux/man/man2/ptrace.2.html 
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Linux alatt Windows vagy fordítva? 4(2. rész) 


Sz 4Lf 


z előző részben befejezett 
VMware-beállítások termését 
fogjuk most learatni. A válasz- 
tott operációs rendszer a Windows 98, 
ennek a telepítését követjük végig 
lépésről lépésre. Miután az előző rész- 
ben bemutatott módon elkészítettünk 
egy virtuális gépet, indítsuk is el. 
Néhány jó tanács a virtuális gépek hasz- 
nálatához. A telepítendő anyagot tartal- 
mazhatja például hajlékonylemez, 
CD-ROM, merevlemez, azonban min- 
denképpen megkönnyíti a dolgunkat, 
ha egy rendszerindításra alkalmas 
CD-ROM-mal kezdünk neki ennek a 
sok türelmet igénylő feladatnak. Az 

1. képen egy hajlékonylemezes rendszer- 
indítást láthatunk. 


Az előkészületek 

Vegyük magunkhoz a telepítőkészle- 
tünket, némi folyadékot és egy jó köny- 
vet (na jó, ez így azért egy kicsit túlzás). 
A telepítés sebessége nagymértékben 
számítógépünk processzorának sebessé- 
gétől és a rendelkezésre álló memória 
mennyiségétől függ, értelemszerűen 
ezek az adatok minél nagyobb értékeket 
mutatnak, annál kényelmesebb és gyor- 
sabb lesz a telepítés. Hajdanán, amikor 
a 233 MHZz-s Pentium I[-es még gyors 
gépnek számított, örvendezve ült az 
ember fél napot a gép előtt, hogy rend- 
szert telepítsen a virtuális gépre, manap- 
ság azonban igen nagy türelemre lenne 
szükségem, hogy egy ilyen napot végig- 
üljek. Általánosságban elmondható 
tapasztalat, hogy legalább 256 MB me- 
mória és egy 1 GHz-s órajelű processzor 
kívánatos a gépbe. 

Mivel az előkészített virtuális merevle- 
mez még nem tartalmaz semmilyen 
lemezrészfelosztást, ezt nekünk kell 
létrehoznunk. Én erre az efdisk prog- 
ramot szoktam használni, ami a rend- 
szerindító lemezemen is megtalálható. 
lermészetesen rábízhatjuk a telepítőre 
is, így nem kell külön programmal baj- 
lódnunk. A 2. képen a merevlemez fel- 
osztását láthatjuk. Minekutána a létre- 
hozott lemezrész 400 MB-os, nem érde- 
mes több részre felosztani; a több giga- 
bájtos lemezeket nyugodtan osszunk 
szét, mintha csak rendes merevlemezzel 
dolgoznánk. Miután ezzel végeztünk, 

a gépet újra kell indítanunk, hogy a 
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változtatások érvénybe lépjenek. lermé- 
szetesen az így létrehozott lemezrészen 
még egy nagyon fontos dolgot végre 
kell hajtani, ez pedig a formázás! 


A telepítés elkezdése 

A 3. és 4. képen egy Windows-telepítés 
jellemző első képernyőképeit láthatjuk. 
Mint már írtam, ez a virtuális gép szinte 
mindenben megegyezik egy szokványos 
PC-vel, így semmilyen trükkhöz nem 
kell folyamodnunk a rendszerek - jelen 
esetben a Windows 98 - telepítése során. 
Miután elfogadtuk a felhasználói szer- 
ződést, és megadtuk a sorozatszámot, 

a szokványos telepítési lépéseket kell 
megtennünk. Az 5. képen éppen a 
Telepítési típus-t választom ki. Ezek után 
már csak a 6. képen látható , Dőljünk 
hátra és ámuljunk" van hátra. Majd jön 
a 7. képen látható Felkészülés a Windows 
98 első indítására... képernyő. 

Legvégül megkapjuk a Windows 
,barátságos" felületét. 


A telepítés 

Mint fentebb írtam, nagyon megköny- 
nyítheti az életünket, ha rendszerindí- 
tásra alkalmas CD-ROM-unk van. Ezt 
csak behelyezzük a meghajtóba, és 
elindítjuk a beállított virtuális gépet, 
és lám, mintha csak egy igazi gép előtt 
ülnénk, elindul a telepítő. Ezekután 





ban ót Lis an öz a MLLE 





a rendszer telepítése következik. Jó 
tanácsként viszont mindenképpen szem 
előtt tartandó, hogy ha a nem megfelelő 
beállításokkal telepítünk egy virtuális 
gépet, nagy sebességveszteség lesz a 
jutalmunk - tehát ne próbáljunk meg 
Windows 98-hoz beállított virtuális 
gépen Linuxot telepíteni. 


Finomhanyolás 

Valószínűleg senki sincs megelégedve 
VMware gépének a színmélységével, 
mivel ez a normál VGA-felbontás 

16 színnel. Ezt tudjuk kiküszöbölni 

a VMware Tools segítségével. Ha ezt 
bekapcsoljuk, máris lehetőségünk nyílik 
a képernyő felbontásának és színmély- 


e EZEL 


ségének a beállítására. A Settings menü- 
pontban válasszuk ki a VMware Tools 
Install menüt, ekkor ez a kiegészítés 
telepíti önmagát. Nagyon fontos, hogy 

a Windowsnak futnia kell, miközben ezt 
a lehetőséget bekapcsoljuk, de a hasz- 
nálatához indítsuk újra a gépet. 
Újraindítás után még nem történik 
semmi, csak annyi változik meg a rend- 
szerben, hogy lesz még egy meghajtónk, 
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ez az én esetemben a D: lett. Különféle 
virtuális eszközeinkhez ezen a meghaj- 
tón találhatjuk meg a meghajtóprog- 
ramokat. A Setup könyvtárban találunk 
egy setup.exe nevű fájlt, ezt futtassuk le, 
és már kész is a telepítés. A rendszer 
ezután szeretne újraindulni — természe- 
tesen újra is indítjuk, amikor pedig a 
Windows újra elindul, már 800 xX600-as 
felbontásban, 16-bites színmélységben 
élvezhetjük eddigi fáradozásaink gyü- 
mölcsét. Ezekután nem kell nyomkod- 
nunk a CTRL-HÁLT billentyűket, hogy 

a virtuális gép , elengedje" az egeret: 

ha kihúzzuk a VMware szélére, rögtön 
megteszi. 

A másik, általam nagyon kedvelt szol- 
gáltatás a teljes képernyős üzemmód, 
amivel nagyon kellemesen csőbe tudom 
húzni az ismerőseimet: amikor meglát- 
ták, hogy a laptopomon Windows fut és 
hogy abban végzem a szövegszerkesz- 
tési feladataimat, szinte egyszerre nyúl- 
tak a telefonjukért, hogy mentőt hívja- 
nak hozzám, mondván biztosan történt 
velem valami, ami semmi esetre sem 
nevezhető jónak! lapasztalataim szerint 
a program teljes képernyős módban 


Szabadon hozzáférhető 

operációs rendszerek: 

AtheOS, könnyen kezelhető 
grafikus operációs rendszer 

2 http:/Avww.atheos.cx/ 

Syllable, az AtheOS-ből fejlődött ki 
5 http://syllable.sourceforge.net/ 
A BSD-k: 

2 http:/Avww.freebsd.org 

2 http:/Avww.netbsd.org 

2 http:/Avww.openbsd.org 
DOSÍTJogtszám 

2 http:/Avww.freedos.org/ 

Solaris 8, a SUN remek operációs 
rendszere 

2 http:/Avwws.sun.com/lsoftware/ 
solaris/binaries/ 

BeOS 

2 http:/Awvww.bebits.com 

Linuxok a teljesség igénye nélkül 
(bár ezt mindenki tudja) 

2 http:/Awvww.debian.org 

2 http:/Avww.redhat.com 

2 http:/Awww.suse.de 

2 http:/Awww.linux-mandrake.com 
A szabad operációs rendszerek 
gyűjtőhelye: 

2 http://www.freeos.com 


sokkal gyorsabban válaszol mindenre, 
mint az ablakosban. 

Attól függően, hogy a VMware telepíté- 
sekor a hálózati kapcsolatot hogyan 
állítottuk be, most azt is beállíthatjuk, 
hogy a virtuális gépünkből is láthassuk 
az Internetet, a helyi hálózatot, vagy 
amit csak akarunk. 

Nos, a Windows 98 telepítése befeje- 
ződött, ezzel is bebizonyítottuk, hogy a 
VMware még a Microsoft rendszereit is 
futtatni tudja. lermészetesen nemcsak 
ezeket a rendszereket lehet futtatni, 
hanem minden olyan rendszert, ami az 
1386-os processzorcsaládra íródott. 
Mint a kapcsolódó címekből is látható 
találhatunk bőven olyan operációs 
rendszert ami, szabadon hozzáférhető, 
és a virtuális gépünkben is futtatható. 
Azért választottam azonban ezt a rend- 
szert, mivel valószínűleg mindenki 
valami ehhez hasonlóval fogja kezdeni 
az ismerkedést. 


Csontos Gyula 
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Felhasználói felulet fénysebességgel (2. rész) 


Sorozatunk előző részében megalkottunk egy egyszerű, de működő képnéző 
programot az FLIK (Fast Light Toll Kit) segítségével. Most ezt bővítjük tovább... 


ségének a megteremtése. Azt, hogy a fájlválasztóban 
ezt meg tudjuk tenni, nagyon könnyen elérhetjük: 
akep open cb függvényben (nezoclass.cxx) a New 
F1l File Chooser értékei között írjuk át 
Fl File Chooser: : SINGLE bejegyzést 
Fl File Choosr: :MULTTI-ra. Így a kiválasztó már megen- 
gedi, hogy több fájlt jelöljünk ki. Hátravan azonban még ezek 
kezelése a programunkban. 
Először is el kell döntenünk, hogy hol és hogyan tároljuk 
ezeket a fájlokat (eddig nem volt rá szükség, mivel azonnal 
megnyitottuk őket, és csak a képet tároltuk). Számomra a 


El s a 


E egyen az első feladatunk a többképkijelölés lehető- 


együtt — egy karaktermutatókból álló tömbön keresztül érjük 
el. Legyen ez egy globális változó, hogy mindenhonnan el 
lehessen érni. Ezenkívül pedig két változót használunk a tömb 
méretének, valamint az aktuális tömbindexnek a tárolására. 

A nezo.cxx fájlban definiáljuk, a nezoclass.cxx-ben pedig 
utalunk rá: 


char F"rfajlok; 

int siz-20; 

int anum; 

illetve 

extern char frfajlok; 
extern int siz; 
extern int anum; 


A nezo. cxx init () függvényében tárhelyet foglalunk az indu- 
ló tömbnek, és a tömb első elemének (NULL) kezdőértéket adunk: 
: fajlok-(char"")malloc(sizeof(charyr) ? ::sSsiz); 
: :tájlok[o]l-(char Y)ü; 


Ha már a keptar.cxx fájlt szerkesztjük, módosítsuk még egy 
helyen - így többet már nem is kell hozzányúlnunk ezen 
részen belül. Ha úgy állítjuk be a programot, hogy indításkor 
a parancssorban meg lehessen adni egy képfájl nevét, amit a 
logó helyett megnyit, lehetőségünk lesz rá, hogy programun- 
kat alapértelmezett képnézőként állítsuk be más programok 
vagy akár a teljes grafikus felületünk számára. Ez könnyen 
megoldható (szebb lenne, ha részletesebben elemezné a pa- 
rancssort; de mivel a legrosszabb, ami ebből adódhat, az, hogy 
ha a fájl nem létezik, nem nyitja meg; vagy nem kép, esetleg 
nem jól adtuk meg a parancssorban, nincs rá igazán szükség). 
Ha van parancssori érték, azt megpróbálja megnyitni, ha nincs, 
marad a logó. A main függvényt kell módosítanunk a 

Kep Nez Wnd() utáni és a show () előtti részben: 


1f£ (argasi) ( 
: kep nez wnd-:loadkep(argv [1] ) ; 


] 


else ( 
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::kep nez wnid-zlősádkepít"lLogo.]1pg") 7 


i 


Térjünk vissza a több fájl betöltése témára! A kep open cb 
visszahívandó függvényt fogjuk tovább módosítani. Az első 
tudnivaló: az FI File Chooser elemből a count () tag- 
függvénnyel lehet lekérdezni, hogy a felhasználó hány fájlt 
választott ki. Ha ez nulla, akkor a Mégsem gombbal, vagy az 
ablakkezelőn keresztül csukta be az ablakot, egyébként a fájlok 
számát mutatja. Az értékeket a value (int) tagfüggvény 
adja vissza, egytől sorszámozva - tehát erre kell szerveznünk 
egy ciklust. Íme a kód (az F1 : : wait () utáni részt kell 
eszerint módosítani): 


if((j-kep opener-s5count ( ) ) ) ( 
for(i-O;icj;i44)( 
fajlok [anum] -strdup (kep opener-:value(i-r1) ) ; 
anumi-t ; 
if (anums-siz) ( 
—fajlok-(char"r)reallocí(fajlok, 
ssizeof(char XY) Fr 2 F siz; 
siz- 2 § siz; 
] 
] 
::kep nez wnd-sactusanum-] ; 
: :kep nez wnd-slőádkep (kep öpener-s 
value (1) ) ; 
: :kéep nez wnd-sredraw ( ) ; 


] 


Mint észrevehető, a tömb méretét - ha betelne - a kétszeresére 
nagyítjuk. A fájlelérési utak és -nevek karakterei számára a 
strdup foglal memóriát. Ezt fel kell szabadítani, ha a listát 
töröljük; a felszabadításakep close cb függvénnyel történik. 
Mielőtt elfelejteném: a Kep Nez Wnd meghatározásánál hozzá 
kell adni az int actu; adattagot, mivel ezt fentebb 
használjuk. A legegyszerűbb, ha a megadott címről letöltjük 

a fájlokat, és az itt leírtakat csak magyarázatként használjuk. 
Ezzel a programnak már több fájlt meg tudtunk adni. 

A következő lépés az, hogy meg is tudjuk őket nézni. 

Akep open cb új változata az újonnan kiválasztott képek 
közül az elsőt jeleníti meg (kep opener-:value (1) ), és 

ezt is teszi pillanatnyilag láthatóvá. Mivel azt szeretnénk, ha 
lépkedni tudnánk a képek között, valamilyen eseménykezelést 
kell megvalósítanunk. Eddig is cél volt, hogy külön kezelő- 
elemek nélkül, gyorsbillentyűk segítségével tudjuk használni 

a programot, most eszerint folytatjuk. Ennek megfelelően a 
Kep Box leíró tagfüggvényét kell bővíteni, mivel ez kezeli az 
eseményeinket. Adjunk hozzá a PG DN, PG UP, HOME és END 
billentyűkhöz is a kódot a kapcsolón belül. A forrásszöveg 
alapján egyértelmű, hogy a hatásukra mit csinál. 

Szintén itt látható egy olyan kódrészlet, ami következő célunk 
megvalósításához tartozik. A fenti léptetőgombok ugyanis 


kikapcsolják az önműködő lejátszást. lekintsük át ennek a 
megvalósítását! Az FLIK-ban az időzített feladatok elvégzésére 
az FI osztály add timeout (double time, 

F1l Timeout Handler callback) függvényét; eltávolításra 
a remove timeout (callback) ; újraindítására pedig a 
repeat timeout (double time, callback) ; függvényeit 
használhatjuk. Sejthető, hogy az első a programhoz egy 
időzített eseménykezelőt ad hozzá. Ez úgy működik, hogy 

a megadott másodperc után (mivel ez egy double érték, 
tetszőleges tört is megadható) meghívja a megadott függvényt. 
Elvileg egy mutatót is átadhat értékként, ezt itt nem hasz- 
náljuk, alapértelmezett értéke NULL, így nem kell megadnunk. 
A remove timeout (callback) a megadott függvényt 
távolítja el az időzített feladatok közül. A repeat timeout 
célja az, hogy magán az időzített függvényen belül meg 
lehessen hívni, azért, hogy a megadott idő múlva a rendszer 
újra meghívja. Érdekes megoldása az FLTK-nak, hogy ilyen 
esetben az idő mérése akkor indul el, amikor a függvény 
visszatér, azaz (elvileg) független attól, hogy a függvény 
mennyi munkát végez, vagy hogy az adott esetben milyen 
bonyolult a végzendő feladat. Az előző részből már ismert 
menu popupl1 tömbhöz két pontot adunk Lejátszás indul és 
Megáll szöveggel. Ezek visszahívandó függvényeiben indítjuk, 
illetve töröljük az időzített függvényt (hajto tocb), 
amelyben elvégezzük a képcserét, a pillanatnyi tömbindex 
állítását, valamint az időzítő újraindítását (repeat timeout). 
Így már működik az önműködő képváltás! 

Van még néhány új képessége képnézőnknek az előző válto- 
zathoz képest (ezért a változatszám fel is ugrik 0.4-re, mert 
annyival jobb). Ezek közül még egyet ismertetnék részletesen, 
a többi sorsát a forrásszövegre utalva az olvasóra bízom. 

Ha a kép nagyobb, mint amit az ablakunkban meg tudunk jele- 
níteni, kicsinyítünk rajta — így azonban a részletek nem látsza- 
nak. Mármost megvan a lehetőségünk arra, hogy a képet nagyít- 
suk, de akkor jelenleg a kép kívánt részét csak a görgetősávokkal 
tudjuk behozni az ablak látható részébe. Ez nem kényelmes, 
ezért módosítunk rajta. Egyfelől a kurzormozgató billentyűk 
(nyilak) segítségével görgetni tudjuk a képet, ehhez aKep Box 
leíró tagfüggvényéhez kell a megfelelő bejegyzéseket hozzáadni, 
másrészről pedig azt szeretnénk, ha a képet az egérrel megra- 
gadva húzni lehetne az ablakon belül (mint például az Acrobat 
Readerben vagy a Gimpben a kijelölések esetében). 

A dolgok egyszerűbbé tétele érdekében készítettem néhány tag- 
függvényt aKep Nez Wwnd osztályhoz, ezek: a bal scroll, a jobb 
scroll, a fel scroll és a le scroll. Mindegyik egy egész értéket 
fogad, és annyival görgeti a képet a megfelelő irányba, ameny- 
nyivel az lehetséges. Ha nullát adunk át, akkor nagyjából a kép 
1/3 részével görget tovább (ezt használjuk a gombokkal való 
görgetésnél). Szintén kezeli, ha többet akarunk görgetni, mint 
amennyit lehetne. Így már egyszerűbb megírni az esemény- 
kezelő részt. A gombokkal való mozgatás ezután egyértelmű. 
Az egérrel való mozgatáshoz a leíró függvényt ki kell bővíte- 
nünk. A külső kapcsolóhoz hozzá kell adnunk az egérgomb- 
lenyomás, -vonszolás (lenyomva mozgatás) és -felengedés 
eseményeit. Ezek a következők: FL PUSH, FIL DRAG, 

FL RELEASE. Az első és utolsónál azt is megnézzük, hogy a 
bal gombról (event buttoni1-() ) van-e szó. A vonszolásnál 
erre nincs szükség, ugyanis az FLIK-ban egy elem csak akkor 
kapja meg a vonszolás eseményt, ha előtte a gomblenyomás 
eseményt , elvette". Azaz, ha azt adnánk vissza az esemény- 
kezelőből, hogy az egérgomb esemény nem érdekel bennünket 
(mint Kep Box-ot), akkor a vonszolást meg se kapnánk. Ha 

az egyes egérgomb okozta az eseményt, akkor lenyomásnál 
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beállítjuk a fog nevű, jelen esetben jelzőként (flag) működő 
változót, hogy benne vagyunk a mozgatási folyamatban, és 
tároljuk az esemény helyét. A vonszolás eseménynél ezután az 
új esemény koordináták alapján eldöntjük, hogy merre kell 
mozdulni, és meghívjuk a megfelelő scroll tagfüggvény(eke)t. 
Még néhány szó arról, mivel bővült a program az előző rész- 
hez képest: 
e — leljes képernyős mód - az FLIK beépített 
F1l Window: :fullscreen() módja segítségével. 
e A pillanatnyi fájlnév kiírása az ablak címsorába az 
F1l Window: : label () tagfüggvény segítségével. 
e Egyszerű segítségablak biztosítása az FI Help View elem 
segítségével, html formátumú állomány beolvasásával. 


e  Nagyításnál az előző méret képközepének az ablak 
közepén tartása, ha a kép már nagyobb az ablaknál. 


A képnéző program további fejlődését nyomon követhetik a 

2 http:/demo.hmvhely.hu/ címen, ahová igyekszem feltenni 

az új változatot, valamint a 45. CD-mellékleten, a 

Magazin/FLIK könytárban. 

Végezetül további kedvcsinálónak még néhány projekt, amiket 

az FLIK segítségével írnak: címeiket az FLTK honlapjáról 

(2 http:/www.tltk.org) kiindulva találhatjuk meg. 

Elemek: 

e Fl Menu Bar - a hagyományos, felül elhelyezett 
legördülő menük megvalósításához. 

e  Fl Button- és alfajai a legkülönbözőbb 
nyomógombokhoz. 

e  Fl Preferences - a Windows registryhez hasonló, 
szövegszerkesztővel is kezelhető adatbázis jellegű, beállítási 
adatok tárolására tervezett elem. Ezt használja például az 
F1l File Chooser a kedvencek eltárolására. 

e  Fl Roller - a régi hangkártyákhoz vagy a legtöbb CD- 
olvasó elején látható forgatógombhoz hasonló jellegű elem, 
ami az egér segítségével vonszolással forgatható. 

e Fl Tooltip- a lebegő segítségekhez. 


Programok, projektek: 

e Fl Photo - kép- és digitális kamerakezelő program. Elég sok 
külső könyvtár is szükséges hozzá, viszont jelenleg is hevesen 
fejlesztik, a 0.4 változattól rövid idő alatt eljutott a 0.9-ig. 
Lehet, hogy a cikk megjelenése idején már kész lesz az 1.0 is. 

e — Teljes ablakkezelő FLIK-ban írva: a Bill Spitzak által írt 
f1wm, valamint a jelenleg is fejlesztett Eguinox. Ehhez az 
utóbbihoz sok segédprogram is készen van már, viszont az 
FLIK fejlesztési változatát, a 2-est használják. 

e  Ímview képnéző és -analizáló program (csak nézéshez nem 
igazán kényelmes, viszont sok mást tud). 

e . 3D-planetárium, valamint sok-sok kisebb segédprogram 
és az FLIK-ba még be nem vett elem. 


Véleményem szerint érdemes megnézni az FLIK-t, mert egy- 
részt rendkívül logikusan megírt eszközkészlet, kicsi, gyors, 
rugalmas; emellett Linux/Unix, valamint Windows és Mac alatt 
egyaránt használható, másrészt felhasználási szerződése telje- 
sen nyitott, még üzleti célú programot is fejleszteni lehet vele. 


Havránek Ferenc 

Automatikamérnökként dolgozik. Kedvtelései közé 
tartozik mindenféle kétkerekű járművön (kerékpár és 
motor) való közlekedés. Ezenkívül szívesen tölti idejét 


zetben Is, például mikrovezérlő programokat ír. 


2003. március 49 


e KEZELT 


0 Kiskapu Kft. Minden jog fenntartva 


programozással, nemcsak PC-s, hanem egyéb környe- 
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A PHP története 


Hihetetlennek tűnik, de a PHP már közel tízéves múltra tekinthet vissza. 


1994-ben Rasmus Lerdorf a saját honlapján azt kívánta 
AA megtudni, hogy kik olvassák nyilvánossá tett önélet- 

rajzát. Erre a feladatra írt Perl nyelven egy egyszerű 
alkalmazást. Mivel a futtató kiszolgáló eléggé túlhajszolt volt, 
és a program emiatt többször feladta a harcot, Rasmus úgy 
döntött, hogy az egészet újraírja C-ben. 
Történetesen ez a kiszolgáló, ahol ügyködött, számos más fel- 
használónak is otthont adott, akik felfigyeltek a munkájára. 
Többen megkérték, engedje meg számukra, hogy ezt a megol- 
dást a saját lapjukon is használhassák. Rasmus hajlott a do- 
logra, aminek rövidesen az lett a következménye, hogy egyre 
több kívánságot teljesíthetett programja továbbfejlesztésével 
kapcsolatban. Látva a dolog sikerét, munkáját leírással ellátott 
programcsomaggá állította össze, és levelezőlistát indított. 
Ekkor kapta meg a program a nevét: Personal Home Page 
Tools. Ez rövidesen Personal Home Page Construction Kit 
névre módosult. Közben adatbázis-kiszolgálókkal is játszadozni 
kezdett, és összeütött egy másik alkalmazást, ami által képes 
volt SOL-lekéréseket összekapcsolni a hozzájuk tartozó webes 
űrlapokkal és listákkal. Ezt a csomagját Form Interpreter néven 
ismerhette meg a nagyközönség. 
A dolgok felgyorsultak, 1997 végére a két program PHP/FI 2.0 
néven egyesült, amihez mind a két összetevőt alaposan át 
kellett írni. Innentől számítható a PHP önálló programnyelv- 
nek, olyannak, amelyet weblapokba ágyazhatóan lehetett fut- 
tatni. Mire a 2.0-s változat próbaváltozatainak a végére ért, és 
végleges pompájában kiadásra került, megnőtt a támogatott 
adatbázis-kiszolgálók száma is. E próbaváltozatok folyamán 
került be a MySOL-adatkapcsolat támogatása is a nyelvbe. 
A PHP C nyelvű forrása ekkor még kényelmesen elfért egyet- 
len könyvtárban. A 2.0 végleges kiadásakor is csak a regexp- 
támogatás kapott kitüntetett helyet, azaz saját alkönyvtárat. 


A csapatmunka eredménye 

És eljött 1998 nyara, vele együtt pedig a PHP 3.0-s változata. 
Ez a kiadás már jelentős csapatmunka eredménye — Zeev 
Suraski és Andi Gutmans nagyfokú közreműködésével. Ők 
ketten teljesen a nulláról indulva újra felépítették a PHP pa- 
rancsfájl-feldolgozó motort. Ez a mag az, amit ma Zend néven 
ismerünk. A PHP rövidítés ekkor nyerte el azt az értelmezését, 
ami jelenleg is használatos: , PHP: Hypertext Preprocessor" . 

A hármas sorozat szűk kétéves fennállása során rengeteg fej- 
lesztésen ment keresztül, de 2000 tavaszára ismét újabb nagy 
ugrás tanúi lehettünk. 


Minőségi ugrás: a 4-es változat 

A PHP 4.0 valóban ismét nagy változásokat hozott. Maga az 
alapnyelv is jelentősen bővült, és a rendszer magja ekkortól 
támogatta a különféle modulok hozzáírását. A legtöbb PHP3-ba 
épült támogatásból is ilyen modul készült. Egészen idáig a PHP 
csak az Apache webkiszolgálóval működött együtt teljes össze- 
fonódásban, míg más rendszereken csak mint CGI-alkalmazás 
állta meg a helyét. Egyedül a 4.0-val bevezetett egységes, web- 
kiszolgálókkal kapcsolatot tartó alapréteg jelentett áttörést ezen 
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a területen. A PHP belső motorja hivatalosan ekkortól kapta 
meg a Zend elnevezést. 


A jelen 

A nagyobb változatszámugrásoknak mindig megvan az oka, 
miként most is. Több olyan újdonság is bekerült az új válto- 
zatban, amelyek külön-külön is indokolhatták volna ezt az 
ugrást. Az egyik ilyen fontos lépés a CLI (parancssorbarát 
felület) végleges, immár nem kísérleti jellegű megjelenése. 
Eddig, ha bármilyen feladat ellátásához parancssorból futtat- 
ható PHP-programra volt szükség, nem létezett tökéletes 
megoldás. Márpedig ilyen feladat a komolyabb leterheltséggel 
számoló alkalmazások esetén könnyen előjöhet - elég egy 
komolyabb reklámcsík-kiszolgálóra gondolnunk. 

A reklámok véletlenszerű elosztását ekkor összetett szempon- 
tok alapján, viszonylag bonyolultabb számításokkal határoz- 
hatjuk meg. E valószínűségeket minden egyes letöltéskor meg- 
határozni és az alapján sorsolni túlzott és felesleges terhet 
jelent a gép számára. Ehelyett elegendő néhány percenként 
kiszámítani a megjelenési valószínűségeket, majd a következő 
időszakban eszerint küldeni a reklámokat, immáron letöltésen- 
ként egyetlen egyszerű kockadobással döntve. A meghatáro- 
zott időközök crontab felállításával könnyedén létrehoz- 
hatók. Igen ám, de a PHP arra született, hogy HTIP-protokol- 
lon keresztül dolgozzon, nem pedig a héjból hívva. Arra a 
feladatra, hogy a PHP-kódok a cron segítségével mégis 
futtathatók legyenek, több megoldás is elterjedt: 


e A Lynx szöveges böngésző felhasználásával, ami némi 
kivetnivalót hagy maga után, hiszen egy felesleges áttételen 
keresztül indítjuk be PHP-kódot. 

e Az Apache-modul mellé egy CGI-változat fordításával és 
ennek parancssori hívogatásával. Ez már kiszolgálóbarátabb 
megoldás, de még mindig nem az igazi módszer. 

A 4.3.0-s változattól kezdve immár nem kell kétszer fordí- 
tanunk, ha parancssori elérést szeretnénk, és a Lynx-féle 


trükközés is hamar elfelejthető. Mostantól kezdve amikor 
Apache-modult állítunk elő forrásból fordítással, egyben 
egy CLI felületű parancssorosan futtatható PHP is hadrend- 
be áll. Ez természetesen egy -disable-c1i kapcsolóval 
kikapcsolható. Akkor sem lesz CLI felületünk, ha Apache- 
modul helyett a CGI-változat mellett döntünk. Lássuk, mi- 
féle kedvességekkel kényeztet minket a CI.Í-megvalósítás: 

" Nem ad HITP-fejléceket. 

" Nem változtatja meg a pillanatnyi munkakönyvtárat a 
futó program könyvtárára. 

" A hibaüzenetek nem kapnak HIML-formázást. 

" A szabványos kimenet nem kerül átmeneti tárba, 
minden azonnal megjelenik a konzolon 
(implicit flush). 

" A program futási idejének nincs felső határa 
(max execution time). 

" A meghíváskor átadott tulajdonságok a Sargc és S$argv 
változókon keresztül elérhetők. A register globals- 
ra a CLI hasonlóképp válaszol, mintha Apache alól 
futna. Ennek off állapotba állításakor az Sargc és 
Sargv változók nem jönnek létre, viszonta $ SERVER 
tömbben továbbra is elérhetők. 

" Bevezeti az SIDIN, SIDOUT, STDERR állandókat. Ezek a 
nevüknek megfelelő ki- és beviteli eszközökre mutatnak, 
használatukhoz tehát nem szükséges az fopen ( ) 
hívása. Hasonlóképpen a bezárásukkal sem kell törődni. 
A CLI-t használva a PHP a Perlhez hasonlóképpen 
használható, azaz többféleképpen is futtathatjuk: 

1. A php program. php vagy a php -f program.php 
segítségével. 

2. A -r kapcsoló segítségével közvetlen parancsokat 
tudunk végrehajtatni: php -r 
print r(get defined constants() ) ; " 

3. A bemenetére csöveken át is csatlakozhatunk. 

4.H! /usr/bin/php sort biggyesztve a PHP-parancsfájl 
elejére, azt önállóan is futtathatóvá tehetjük. 


Ugyancsak most bevezetett újdonság az egységesített adatfo- 
lyamkezelés (Stream). A dolog szellemisége a Unix ,minden 
fájl" felfogásához hasonlít. Itt arról van szó, hogy minden ki- és 
bemeneti művelet nagyon hasonlatos egymáshoz, legyen szó 
akár fájlba írásról, csővezetékből való adatfogadásról, memória- 
kezelésről, akár foglalaton keresztüli kapcsolattartásról. Ezeket 
a feladatokat rengeteg különböző, ámde mégis nagyon hasonló 
függvénygyűjteménnyel lehetett eddig megoldani. Foglalatok- 
hoz példaképpen a socket " függvények vannak rendsze- 
resítve, míg FIP-re rengeteg Étp " függvényt találunk. Az 
egységesítéshez a fájlkezelő függvények átírására, valamint 

jó pár stream " eljárás rendszeresítésére volt szükség. A meg- 
lévő függvények egy része viszont ettől fogva már csak ezek- 
nek az adatfolyamféle megfelelőiknek a további neveiként 
lelhetők fel, saját kóddal nem rendelkeznek. Így a 

socket set timeout () önmagában már nem létezik, csak 
a stream set timeout () egy álneve. 

Ez nem csupán a PHP-ben fejlesztők munkáját könnyíti meg, 
de segíti a PHP további C-ben való fejlesztését is, hiszen így az 
újabb protokollok, adatforrások támogatásának bevezetéséhez 
nem kell teljes kezelőt írni, elég ennek a programozási felü- 
letnek a bővítményeit elkészíteni. 

lovábbi újdonság, hogy a GD-támogatáshoz eleddig külön 
telepítendő libgd beszerzése nem szükséges, ugyanis a 4.3.0-s 
és későbbi kiadások már tartalmazzák. A különféle képformá- 
tumok kezelését biztosító külső könyvtárak fejlesztői változa- 
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tára (libjpeg, libpng, libungif) viszont továbbra is szükség lesz. 
E fejlesztések mellett természetesen rengeteg hibát is kijaví- 
tottak benne, az Apache2 SAPI is közelebb került az éles kiszol- 
gálókon való alkalmazhatósághoz. Ez véglegesen majd csak 
valamikor a nyárra várható, és a Zend2-motorra épülő PHP 
5.0-val lesz hivatalosan is használható. 


A jövő: PAP5 és Zend2 


A történet 2001 nyarán kezdődött. Az akkori tervek szerint a 
Zend2-vel felszerelt PHP 5.0 várhatóan egyidőben jelent volna 
meg a 4.1-es változattal. Nos, azóta tudjuk, hogy nem így lett. 
A PHP 5.0-nak rengeteg elvárást kell kielégítenie, ennek megfe- 
lelően sok területen hatalmas előrelépésre lehet számítani. 

A Zend-motor, ami a parancsfájlok feldolgozásáért felel, legin- 
kább az objektumokkal kapcsolatos területen fog látványos 
eredményeket hozni. A PHP-t objektumtámogatottsága miatt 
sok vád érte, mivel a Java vagy a Ct 4 képességeihez képest 
jócskán elmarad. Az egyik ilyen jelentős nehézség a jelenlegi 4- 
es változatokban az, hogy az ,objektumváltozók" magát az 
objektumot tárolják, nem csak egy hivatkozást rá, mint ahogy 
az logikus lenne. Ennek következménye az, hogy minden 
egyes objektumpéldány egy másolat ahelyett, hogy ugyanazon 
objektumra mutatnának. 

A Zend2-ben az objektumkezelés teljesen újra lett írva, ezáltal 

a fenti gondok megoldódnak, és ez utat nyit a komolyabb objek- 
tumalapú programozás felé. Hasonlóan nagy lépés lesz a kivé- 
telkezelés bevezetése. A try, catch, throw használatával im- 
már a PHP is fel lesz vértezve azokkal az eszközökkel, amelyek 
segítségével , kiakadáskerülő" programokat építhetünk. Zeev 
Suraski-nak, a Zend-motor egyik fejlesztőjének véleménye sze- 
rint a PHP ezzel a lépéssel valóban komoly, versenyképes objek- 
tumalapú nyelvvé növi ki magát. Az az előnye is meglesz a web- 
lapba ágyazott Java lehetőségével szemben, hogy a PHP valóban 
pehelysúlyú parancsnyelv. Zeev mindezt röviden úgy foglalta 
össze, hogy a Java pont ilyen lett volna, ha parancsnyelvnek 
tervezték volna. Arra, hogy ténylegesen mik ezek az objektum- 
kezelési újdonságok, egy későbbi cikkemben térek vissza. 
lovábbi apróbb változások a karakterlánc-kezelésben várha- 
tóak. Eddig is létezett az a lehetőség, hogy a karakterláncokat 
karaktereket tároló tömbként kezeljük, de ez egyrészt nem 
működik tökéletesen, másrészt a nyelvi szempontból teljesen 
eltérően kezelendő dolgokat jobb elkülöníteni. Ezért a jövőben 
a karakterláncok későbbi tömbként való kezelése figyelmeztető 
üzenetek megjelenését fogja kiváltani. A Sstr[31] helyett a 
jövőben a Sstr(3 ) forma használandó. A fejlesztők ennyivel 
természetesen nem érték be - ha már ilyen beavatkozás 
történik, érdemes kihozni belőle a legtöbbet. 


Heiglig (Cece) Szabolcs (cececophp.net) 
Veszprémben él. Hobbija, kedvenc időtöltése 
és munkája Is a programozás. Szabadidejében 
hajlamos kerékpárra pattanni, vagy baráti 
társaságban szerepjátékokkal foglalkozni. 





2 http:/Avww.zend.com/zend/future.php 
2 http:/Avww.theopenenterprise.com/story/ 
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Fejlett modellezési eljárások 4(2. rész) 


Sorozatunk második részében négy modellezési eljárással iIsmerkedhetnek meg, 
amelyek megkönnyítik a bonyolultabb formák létrehozását. 





z egyik módszer azon alapul, hogy léteznek olyan testek, 
AA amelyeket könnyedén modellezhetünk kétdimenziós 

alakzatnak térbelivé történő formálásával. Gondoljunk 
például egy csővezetékre vagy egy jövőbeli űrhajó formájára. 


Térbeli kiterjesztés és formafinomítás 
Az első eljárás egyúttal egy másikat tartalmaz, amit a későbbiek 
folyamán a feladathoz igazodva elválaszthatunk tőle. A két 
eljárás: az úgynevezett térbeli kiterjesztés (extrudálás) és a 
formafinomítás (mesh subdivision). Indítsuk el a Blendert, 
majd a szerkesztőnézetet a számbillentyűzet 1-es billentyűjével 
kapcsoljuk elölnézetbe. Első lépésben a test keresztmetszetét 
meghatározó alakzatot kell létrehoznunk. Az űrhajópéldánál 
maradva: hozzunk létre egy alakítható körvonalat (Főmenti- 
Add-Curve-BezierCircle). Húzzuk szét a két oldalsó pontját, 
hogy a téglalap formát lekerekítsük. Amit így létrehoztunk, 
már nagy vonalakban meghatározza a hajótest formáját, de 
nem eléggé részletes. Jelöljük ki az összes szerkesztési pontját, 
majd az alsó szerkesztőmezőben nyomjuk meg az F9-es billen- 
tyűt. Ezzel az alsó szerkesztőmezőt pontszerkesztő módba 
váltottuk át, vagyis az itt található felhasználói felület segítsé- 
gével különféle műveleteket hajthatunk végre a kijelölt ponto- 
kon, görbéken és éleken. A részletek kidolgozásához e gombok 
közül a Subdivide gombra lesz szükségünk, amit a képernyő 
jobb alsó részén találunk meg. A gymb megnyomása után 
láthatjuk, hogy minden eddig meglévő szerkesztési pont kö- 
zött újabbak jelentek meg. Alakítsuk ki a hajótest részletesebb 
formáját, de ne hozzunk létre újabb pontokat. A forma kialakí- 
tása után ezt az alakzatot szeretnénk majd térbelivé tenni, de 
ehhez a görbét a Blender számára egyenes szakaszokból álló 
alakzattá kell átalakítanunk. Az alsó vezérlőfelület középső 
részén négy gombot találunk egymás alatt: Poly, Bezter, 
Bspline, Cardinal, Nurb. A Poly gomb alkalmazásával az alak- 
zatot szögletessé tehetjük, vagyis amellett, hogy a fő vonások 
megmaradnak, egyszerűbb és gyorsabban megjeleníthető 
formájúra alakítjuk. Ezután a TAB billentyűvel kapcsoljunk 
vissza tárgyszerkesztő módba, és az ALI-C kombinációval az 
alakzat körvonalát alakítsuk át síkfelületté. 
A forma kialakítása után a következő lépés legyen a kiterjesztés. 
Kapcsoljunk vissza pontszerkesztő módba, és jelöljük ki az alak- 
zat összes pontját az A billentyűvel. Ezután váltsunk át oldal- 
nézetre, és a billentyűzeten használjuk az E-t. A megjelenő me- 
nüben megerősítjük a szándékunkat, és az egér mozgatásával 
az alakzatot kiterjesztjük. Mozgassuk az egeret oldalirányban, 
majd amennyiben szükséges, méretezzük át a keresztmetszet 
újonnan létrehozott részét, és a fenti két művelet ismétlésével 
alakítsuk ki a hajótest végleges formáját. Az én elképzelésem, 
ami a képünkön látható, csak támpontként szolgál. 
A fentieket követve láthatjuk, hogy a forma még elég durva, de 
már alakulóban van. Formáljuk meg a szárnyakat is. Elölnézet- 
ben jelöljük ki a legszélső pontokat, az S billentyűvel húzzuk 
szét őket, ezután felülnézetben a szárnyak irányát és megfelelő 
elkeskenyedését alakítsuk ki. 
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A körvonalazódó űrhajó 


Most már tényleg elégedettek lehetünk eddigi munkánkkal, 
következhet a finomítás. Szerencsére ezt a műveletet a Blender 
önműködő elvégzi, csak meg kell határozni a szükséges mér- 
téket. Az alsó vezérlőfelület bal oldalán található a mérték 
meghatározására alkalmas gombkészlet. Itt keressük meg a 
SubSurf-öt, majd nyomjuk meg. Ennek hatására a Blender fino- 
mítja a felületet, amelynek mértékét az alatta lévő két számmal 
határozhatjuk meg. A Subd7v felirat mellet található szám a 
szerkesztés közben látható mértéket mutatja, míg a felirattól 
jobbra lévő gombon a számolásnál, a megjelenítésnél szükséges 
finomítási fokot állíthatjuk be. A végleges részletesség beállítása 
után egy szép, áramvonalas űrhajót láthatunk, amelynek már 
csak az anyagát és a mintázatát kell meghatároznunk a sorozat 
folytatásának útmutatásai alapján. 


A NURDBS alapú modellezés 

A következő modellezési eljárás alapja az, hogy bizonyos 
esetekben görbült felületekkel sokkal pontosabban alakítha- 
tunk ki egy-egy formát, mintha pusztán síklapokkal határolt 
felületekkel tennénk. Ez az eljárás felhasználható például az 
emberi test modelljének kialakítására vagy más élőlény model- 
lezésére is. A módszer neve: NURBS alapú modellezés (a rövi- 
dítés a Non Uniform Bezier Spline kifejezésből származik), és 
az egyik fontos tulajdonsága az, hogy a felület az úgynevezett 
ellenőrzőpontok (control point) változtatásával dinamikusan 
módosítható. Ismerkedésünk célja legyen egy egyszerű görbe- 
felület megformálása. Elsőként a ftőmenüből kiindulva az Add- 
Surface-Curve menüpontok kiválasztásával hozzunk létre egy 
NURBS-görbét. Ezt a görbét alakítsuk tetszőleges formájúra, 
ehhez a szerkesztő eszközkészletben már korábban megismert 
(F9) Subdivide eszközt használjuk. Miután a megfelelő profilt 
kialakítottuk, készítsünk másolatokat erről a görbéről, de ne 
feledjük, hogy a NURBS alapú modellezés során az egyes 
profiloknak azonos számú ellenőrzőponttal kell rendelkezniük. 
Ez azt jelenti, hogy miután a másolatok elkészültek, az egyes 
görbékhez csak azonos számú pontot adhatunk vagy törölhe- 
tünk belőlük. A másolatokat a könnyebb szerkesztés végett 
egymástól csak egyetlen tengely mentén toljuk el. Így elérjük, 
hogy a későbbiekben is egyszerűen kiválaszthassuk őket, és az 
egyes görbék szerkesztésekor a pontokat is kényelmesen ki 
tudjuk választani. A másolatokat is egyesével módosítsuk, az 
elképzeléseinknek megfelelően, és amikor elkészültünk, a 
felületet alkotó görbéket tegyük a helyükre. Az elhelyezés után 
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eddigi munkánkról célszerű mentést készíteni. Ahhoz, hogy a 
Blender felületet tudjon feszíteni a görbékre, tudomására kell 
hozni, hogy ezek a különálló pontok tulajdonképpen egy tárgy 





pontjai. A nagyobb koordináták felől a kisebbek felé haladva 
jelöljük ki a létrehozott görbéket. lermészetesen fordítva is 
csinálhatnánk, de a görbék kijelölési sorrendje befolyásolja a 
felület normálvektorainak az állását. Amennyiben a görbéket 
fordított sorrendben jelöljük ki, a felület is kifordított 
állapotban jelenik meg. A kijelölt görbéket ezután tehát egybe 
kell vonni, méghozzá a CIRL-]J billentyűkombinációval. A meg- 
jelenő kérdésre megerősítő választ adva a görbék ezután már 
egy tárgy görbéi lesznek, még akkor is, ha ez a tárgy jelenleg 
csupán görbék halmaza, felület nélkül. A Blender könnyen 
segíthet tárgyunk e hiányosságán, miután pontszerkesztő mód- 
ba váltva (TAB billentyű) a görbesereg minden pontját kijelöl- 
jük. A munka befejezéséhez a végső megoldást az F billentyű 
használata nyújtja, ezzel a Blendert a felület elkészítésére 
utasítjuk. Megjegyzendő, hogy ez a billentyű nemcsak a gör- 
befelület létrehozására használható — ha pontszerkesztő mód- 
ban kiválasztunk három pontot, szintén ezzel a megoldással 
alkothatunk új, az adott tárgyat alkotó háromszöget. 

Az előbb ismertetett eljárás segítségével kis ráfordítással model- 
lezhetjük például egy élő ember fejét is. Ennek megoldásához 
szükség lesz egy körvonalra, amelyet a földre rajzolunk, és az 
egyik negyedét egyenlő részekre osztjuk. A modellként szol- 
gáló személy a kör közepén foglal helyet és egy másik személy 
a körvonalon azonos lépésekben mozogva felvételeket készít 
róla. A felvételeken ezután valamelyik rajzprogrammal kiemel- 
jük a modell arcélét, vigyázva arra, hogy a kamerával ellenkező 
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oldalon lévő éleket ne keverjük össze a fontosabb, közelebbi 
oldalon lévő formák vonalával. A profilok meghatározása után 
ezeket a képeket úgy másoljuk egymásra, hogy a profilt alkotó 
élek mindegyiken jól láthatóak maradjanak. A Gimpben pél- 
dául ezt az átlátszóság felhasználásával oldhatjuk meg, majd 

a végeredményt jpg formátumban tároljuk. A Blender lehető- 
séget nyújt arra, hogy a szerkesztőnézetbe háttérképet töltsünk 
be. A szerkesztőnézeten álló egérmutató mellett nyomjuk meg 
a SHIFT-F7 gombokat, majd a képet töltsük be háttérképként. 

A profilok vonalait követve ezek után rajzoljuk meg a görbéket, 
és forgassuk el őket a felvételek során követett elmozdulások- 
nak megfelelő szöggel. Így már nagy vonalakban láthatóvá 
válik a kialakuló fejforma. Utolsó lépésként a fenti módszerrel 
hozzuk létre a görbékre feszíthető felületet, és az egyes ponto- 
kat szerkesztve alakítsuk ki a végleges formát. 


Blob objektumok használata 

A harmadik modellezési eljárás már ismerős lehet azok szá- 
mára, akik a PovRayról szóló (Linuxvilág 2001. június-július, a 
92. oldaltól) sorozatot figyelemmel kísérték, ugyanis ebben is 
találkozhattunk a Blob objektumokkal. Mint az hamarosan 


kiderül, a Blender is képes ilyen gumilabdához hasonló tárgyak 
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létrehozására, amelyeket a Főmentü-Add-Metaball menüpontok 
segítségével hívhatunk életre. Az első ilyen létrehozott 
objektumnál a szerkesztő eszköztár segítségével meghatároz- 
hatjuk e tárgyak általános tulajdonságait. Az F9 billentyűvel 
elérhető értékek közül a Wiresize határozza meg a szerkesztés 
során használatos számolási pontosságot, a Rendersize a meg- 
jelenítéskor alkalmazandót, míg a Threshold érték a gömböket 
övező erőtér erősségét. A későbbiek során ezeket az értékeket 
csak az elsőként létrehozott gömbnél változtathatjuk meg, és 
ezek a változások a többi ilyen tárgyra is hatással lesznek. 
Minden létrehozott , gumilabdánál" negatív hatású erőtér is 
beállítható, gömbforma helyett pedig hengeralakzatot is kiala- 
kíthatunk, amelyet a három tengely egyikével párhuzamosan 
készíthetünk el. Ebben az esetben lesz értelme a pontszer- 
kesztő módban megjelenő Length értéknek, míg a Stiffness 
értékkel a vastagságot befolyásolhatjuk. 

Végezetül foglaljuk össze a későbbiekben megjegyzendő és a 
munkánkat megkönnyítő billentyűkombinációkat (lásd 
táblázatunkban). Az ilyen összefoglalások esetében a későbbiekben 
is megkülönböztetem majd a tárgyszerkesztő módot (ISZ) a 
pontszerkesztő módtól (PSZ). 

A sorozat következő részében elkezdjük az ismerkedést az 
anyagokkal és a felületi mintázatokkal. lartsanak velem a 
későbbiekben is, és ne feledjük, hogy egy gyakorlati anyag 
elsajátítása során a legfontosabb segédeszköz maga a gyakorlás. 


Modellezés rácsszerkezetek segítségével 

Az utolsó modellezési eljárás a kiindulásul szolgáló tárgyat egy 
tetszőlegesen módosítható térbeli rácsszerkezet segítségével 
formálja át. Első lépésként hozzunk létre egy gömböt az Fő- 
ment-Add-Mesh-Icosphere menüpontokon keresztül. A felosz- 
tás mértékét állítsuk háromra. Ezután a formát kialakító objek- 
tumot szükséges meghatároznunk, ami egy térbeli rács lesz. 

A főmenüből kiindulva az Add-Lattice pontokat kiválasztva 
létrejön egy új kocka. Ennek tulajdonságait szintén az F9 bil- 
lentyű használatával előbukkanó panelen állíthatjuk be. A mó- 
dosító rácsszerkezet jellemzői közül az U, a V, valamint a W 
értékek határozzák meg a módosításhoz használható pontok 
számát: ezeknek az értékeknek a változtatásával a rácspontok 
sűrűsége az értékeknek megfelelő tengely mentén (az U értéke 
az X tengelynek, a V értéke az Y tengelynek, míg a W-éa Z 
tengelynek felel meg) alakul át. A rács felosztását szolgáló 
értékek mellett meghatározhatjuk, hogy a tárgy pontjait milyen 
összefüggés szerint befolyásolják a rácspontok. Ezek közül a 
Lin lineáris összefüggést határoz meg, a Card kapcsoló 
hatására a módosítandó tárgy kissé sarkított lesz, a B pedig a 
Bezier-Spline közelítéssel alakítja át a tárgyat, amelyet később 
hozzárendelünk a módosító rácshoz. Miután létrehoztuk a 
rácsot, és a rácsszerkezetet elképzeléseink szerint átalakítottuk, 
jelöljük ki először az átalakítandó tárgyat, utána a CTRL billen- 
tyűt lenyomva tartva a rácsot is, majd a CTRL-P-vel rendeljük 
őket egymáshoz. Ekkor már jól látható a változtatás ered- 
ménye. Állítsuk be pontosan a rácspontokat az elképzeléseink- 
nek megfelelően , majd a CTRL-SHIFT-A billentyűk alkalmazá- 
sával véglegesítsük a változásokat. 


Fábián Zoltán (dzoolkofreemail.hu, dzooliogyahoo.com) 
26 éves, jelenleg programozóként dolgozik. 
Szabadidejében szívesen kirándul, túrázik. Emellett 
szeret rajzolni, érdekli a 3D-s grafika és a Linuxszal 
kapcsolatban minden olyan program és program- 
nyelv, amit még nem ismer vagy nem próbált ki. 
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Nullmásolás felhasználói szemszögből 


Lássuk, mit takar a nullmásolás fogalma, továbbá mire és hol lehet használni. 


zinte mindenki hallott már a Linux nullmásolási 

(zero copy) lehetőségéről, mégis sok emberrel talál- 

kozom, akik nem teljesen értik a lényegét. Ezért hatá- 
roztam úgy, hogy egy cikksorozatban kicsit mélyebbre ások e 
témakörben, abban a reményben, hogy sikerül eloszlatnom a 
vele kapcsolatos bizonytalanságot. Jelen írásomban felhasználói 
szemszögből vizsgálom a nullmásolást, tehát a rendszermag 
élveboncolását szándékosan mellőztem. 


Mi az a nullmásolás? 

Ha egy kérdésre meg szeretnénk találni a választ, először 
magát a kérdést kell pontosan megértenünk. Vizsgáljuk meg, 
mire van szükség ahhoz, hogy egy egyszerű hálózati démon 
a fájlokban tárolt adatokat az ügyfeleknek átadhassa. 
Példakódunk: 


len) ; 
len) ; 


ééadlitile, tmp but, 
write(socket, tmp buf, 


Elég egyszerűnek tűnik, nyilván úgy gondolod, hogy két egy- 
szerű rendszerhívás végrehajtása nem igényel túl sok munkát. 
Sajnos a valóság messze nem így fest. Bár csak két hívást haj- 
tottunk végre, az adatok másolása legalább négyszer megtör- 
ténik, és legalább ennyi felhasználói- és rendszermagkörnyezet 
váltásra is sor kerül. (Valójában a folyamat ennél is összetet- 
tebb, de nem akarok elmerülni a részletekben.) Az 1. ábrára 
tekintve egy kicsit jobban is átláthatod a történéseket. Felül 
láthatók a környezetváltások, alul pedig a másolási műveletek. 
Első lépés: a rendszerhívás hatására a rendszer felhasználóiból 
rendszermagmódba vált. Az első másolást a DMA-motor végzi 
el, ami beolvassa a lemezről a fájl tartalmát, és egy a rendszer- 
mag címterében található átmeneti tárban tárolja. 

A második lépés során a rendszer felhasználói átmeneti tárba 
másolja az adatokat a rendszermagéból, és visszatér az olva- 
sási hívásból. Most, hogy az adatok bekerültek egy a felhasz- 
nálói címtérben található átmeneti tárba, megkezdhetik lefelé 
tartó útjukat. 

Harmadik lépésben az írási hívás hatására a rendszer felhasz- 
nálóiból rendszermagkörnyezetbe vált. A harmadik másolás 
során az adatok újra egy a rendszermag címterében található 
átmeneti tárba kerülnek. lermészetesen itt egy másik, kifejezet- 
ten a foglalatokhoz tartozó átmeneti tárról van szó. 

A negyedik lépés az írási hívás visszatérése, ezzel megtörténik 
a negyedik környezetváltás. Ettől független és aszinkron 
módon egy negyedik másolás is lezajlik, amikor a rendszermag 
átmeneti tárában található adatokat a DMA-motor átadja a 
protokollmotornak. lalán felmerül benned a kérdés: , Mi az, 
hogy független és aszinkron módon? Hát nem történt meg az 
adatok átvitele még a hívás visszatérése előtt?" Az, hogy maga 
a hívás visszatér, önmagában még nem biztosítja a másolás 
tényleges elvégzését, sőt még annak megkezdését sem. Egysze- 
rűen csak annyit jelez, hogy az ethernet illesztőprogram váró- 
listájában voltak szabad leírók, és amit adtunk neki, azt elfo- 
gadta átvitelre váró adatként. Lehet, hogy jó néhány csomag 
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van még a várólistában a miénk előtt. Hacsak maga az eszköz 
vagy az illesztőprogram nem állít fel fontossági várólistákat, 
az adatok küldése érkezési sorrend szerint történik. (Az 1. ábra 
fork hívással párosuló DMA-másolása is jelzi, hogy az utolsó 
másolás késlekedhet.) 


write előtt 


write előtt 


; felhasználói meni) 


felhasználói környezet 


rendszermag környezet rendszermagkörnyezet 


syscall read syscall write 


T 
2 CPU-másolás 3 
1, r 7 


2 
lépések 


1. ábra Másolás két rendszerhívással 


Mint láthatod, a cél eléréséhez egyáltalán nem lenne szükség 
ennyi adatmásolásra. Ha a másolgatások számát sikerülne 
csökkenteni, egyben a rendszer terhelése is kisebb lenne, 

így növekedne a teljesítménye. Illesztőprogram-fejlesztőként 
közvetlenül a vassal dolgozom, és bizony találok érdekes 
lehetőségeket. Egyes eszközök képesek megkerülni a köz- 
ponti memóriát, és közvetlenül a másik eszköznek adni át az 
adatokat. Így teljesen szükségtelen másolatot készíteni a 
központi memóriába, meg úgy általában véve nekem tetszik 
a dolog, de sajnos nem minden eszköz képes erre. Arra is 
gondolni kell, hogy a lemezről beolvasott adatokat a hálózat 
igényeinek megfelelő formátumba át kell csomagolni - és 
máris kezdünk , bonyolódni". A többletterhelés csökkentése 
érdekében először próbáljuk meg kiküszöbölni a rendszer- 
mag átmeneti tár és a felhasználói átmeneti tár közötti 
másolásokat. 

Az egyik lehetőség a másolás elhagyására a read hívás 
mellőzése és az mmap használata. Például: 


len) ; 
len) ; 


mmap(file, 
Co: DUt , 


tmp.but e 
write(socket, 


A folyamatot a 2. ábra szemlélteti. A környezetváltások 
változatlanok. 

Elsőként az mmap rendszerhívás hatására a DMA-motor a fájl 
tartalmát egy rendszermag átmeneti tárba másolja. Ezután a 
rendszer az átmeneti tárat megosztja a felhasználói folyamattal, 


write előtt 


mmap előtt 


3 felhasználói ty) 


felhasználói környezet 


felh. körny. 


rendszermagkörnyezet rendszermagkörnyezet 


syscall mmap syscall mmap 


I 
2 3 


felhasználói felület ! feltiasználói átmeneti tár ! 
: : DMA-másolás : 


2 
lépések 


2. ábra Az mmap használata 


sendfile előtt 


felhasználói környezet felhasználói környezet 


rendszermagkörnyezet 


syscall sendfile 


3 
felhasználói felület ! 


CPU-másolás DMA-másolás 


1 or ! 
mág átmeneti tár foglalat puffer 


. . rendszermagfelület 


DMA-másolás 


2 
lépések 


3. ábra A read és a write hívások kiváltása sendfile hívással 


a felhasználó és a rendszermag memóriaterülete között nem 
végez másolást. 

Másodikként a write rendszerhívás hatására a rendszermag 
az adatokat a foglalatokhoz rendelt átmeneti tárba másolja. 

A harmadik másolás akkor történik, amikor a DMA-motor az 
adatokat átadja a rendszermagfoglalat átmeneti tárból a 
protokollmotornak. 

Azzal, hogy read helyett mmap hívást használunk, felére csök- 
kentettük a rendszermag által másolandó adatok mennyiségét. 
Már ezzel is számottevő eredményt érhetünk el, ha nagy 
mennyiségű adatról van szó. Csakhogy megfizetjük az árát is, 
az mmap és write használatának bizonyos buktatói is vannak. 
Az egyik lehetséges hiba az, amikor memória-hozzárendelést 
hozol létre egy fájlhoz, majd write hívást hajtasz végre, de 
közben egy másik folyamat ugyanezt az állományt csonkolja. 
Az írási műveletet egy SIGBUS sínhibajelzés fogja megszakí- 
tani, ugyanis hibás memóriaeléréssel próbálkoztál. Alapesetben 
a hibajelzés a vétkes folyamat kilövését okozza és memóriaki- 
íratással jár, ezt viszont hálózati kiszolgálóknál általában igyek- 
szünk elkerülni. A gondot kétféleképpen oldhatjuk meg. 
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Az első lehetőség egy jelkezelő (signal handler) telepítése a 
SIGBUS jelzéshez, majd egyszerű visszatérést alkalmazni a 
jelkezelőben. Így a write rendszerhívás a megszakítás előtt 
sikeresen kiírt bájtok számával tér vissza, az errno pedig sikert 
jelez. Hadd mutassak rá, miért rossz ez a megoldás: csak a 
tüneteket kezeli, de az okot nem szünteti meg. A SIGBUS azt 
tudatja velünk, hogy az adott folyamat kapcsán valami nagyon 
rosszul sült el, így ettől a módszertől inkább tartózkodnék. 

A másik megoldás a fájl kibérlése (file leasing) a rendszer- 
magtól, amit a Windows világában alkalmi zárolásnak is nevez- 
nek. A bérlést végrehajtva a fájlleírón a fájlt ideiglenesen 
bérletbe veheted. Ezt követően olvasási, illetve írási bérlést 
kérsz a rendszermagtól, így amikor a másik folyamat az éppen 
küldött fájlt megpróbálja csonkolni, a rendszermag egy valós 
idejűRT SIGNAL LEASE jelzést küld neked. Így tudomásodra 
juthat, hogy a rendszermag megszünteti a fájlra szóló 
ideiglenes bérletedet. Írási hívásod még azelőtt megszakad, 
hogy a programod érvénytelen címhez férne hozzá, és a 
SIGBUS hibajelzés miatt idő előtt elhalálozna. A write hívás 

a megszakítás előtt sikeresen kiírt bájtok számát adja vissza, az 
errno pedig sikert jelez. Az alábbi példa szemlélteti, hogyan 
lehet fájlt bérelni a rendszermagtól: 


if(fentl(fd, F SETSIG, RT SIGNAL LEASE) -- -1 ( 
perror ( "rendszermag bőrlős 
bekll tEsa!") ; 
return -1; 


] 


/7 l type Öörtőke F RDLCK vagy F WRLCK 
lehet F/ 
if(fentl(fd, F SETLEASE, 1 type) ) ( 
spgorlgost pus beXll tEsa") ; 
return -1; 


] 


A bérlést az mmap használata előtt kell végrehajtanod, és csak 
miután végeztél, szabad megszüntetned. Utóbbit az fecnt1 

F SETLEASE hívásával érheted el, a bérlés típusát F UNLCK 
értékre állítva. 


Sendfile 


A 2.1-es változatú rendszermagban jelent meg a hálózati vagy 
két helyi fájl közti adatátviteleket leegyszerűsítő sendfile 
rendszerhívás. A sendfile révén nemcsak a másolások, 
hanem a környezetváltások száma is csökkenthető. Használata 
a következő: 
sendfile(socket, file, len); 

A folyamatot a 3. ábra szemlélteti. 

Először a sendfile rendszerhívás hatására a DMA-motor a 
fájl tartalmát egy rendszermag átmeneti tárba másolja. Ezután 
az adatokat a rendszermag a foglalatokhoz rendelt átmeneti 
tárba másolja. 

Másodszor: a harmadik másolás akkor zajlik le, amikor a DMA- 
motor a rendszermagfoglalatokhoz rendelt átmeneti tárában 
található adatokat átadja a protokollmotornak. 

Nyilván eszedbe jut, hogy vajon mi történik, ha egy másik 
folyamat csonkolja az éppen sendfile rendszerhívással 
továbbított állományt? Ha nem jegyzünk be jelkezelőt, a 
sendfile egyszerűen a megszakítás előtt sikeresen átvitt 
bájtok számával visszatér, és az errno is sikert jelez. 
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sendfile előtt 


felhasználói környezet felhasználói környezet 


rendszermagkörnyezet 


syscall sendfile 


felhasználói felület 


dscr megnyitás 


mág átmeneti tár 


: . rendszermagfelület 


DMA-másolás 


lépések 





4. ábra A gyűjtögetést támogató eszköz képes arra, 
hogy több memóriarészből olvassa ki az adatokat, 
így eggyel kevesebb másolásra van szükség 


Ha még a sendfile meghívása előtt kibéreled a fájlt a 
rendszermagtól, változatlan viselkedést és visszatérési értéket 
tapasztalsz. Megkapod a már ismert RT SIGNAL LEASE 
jelzést is, mielőtt még a sendfile visszatérne. 

Az eddigiek alapján sikerült elkerülnünk, hogy a rendszermag 
nagyszámú másolást végezzen, de egy másolás még hátravan. 
Vajon ezt is el lehet hagyni? lermészetesen igen, ha a vas is 
nyújt hozzá némi segítséget. Ha el szeretnénk felejteni a rend- 
szermag által végzett adatkettőzéseket, akkor az adatgyűjtést 
támogató hálózati csatolóra van szükségünk. Ez mindössze 
annyit jelent, hogy a továbbításra várakozó adatoknak nem 
muszáj összefüggő memóriaterületen lenniük, hanem több 
helyre is szétszórhatók. A 2.4-es rendszermagban a foglalat 
átmenetitár-leíróját úgy módosították, hogy teljesíti ezeket 

a követelményeket - Linux alatt ezt nevezzük nullmásolásnak. 
Az elgondolás révén nemcsak a többszörös környezetváltás, de 
a processzor által végzett adatkettőzések is elhagyhatók. A 
felhasználói alkalmazások szemszögéből nézve semmi sem 
változott, a kód továbbra is így alakul: 

sendfile(socket, file, len) ; 

A lezajló folyamatot a 4. ábra szemlélteti. 

Első lépésként a sendfile rendszerhívás hatására a DMA- 
motor a fájl tartalmát egy rendszermag átmeneti tárba másolja. 
Második lépésben az adatok másolása helyett a rendszer csak 
a helyüket és a méretüket megadó leírókat fűzi hozzá a foglalat 
átmeneti tárhoz. A DMA-motor a rendszermag átmeneti tárból 
közvetlenül a protokollmotornak adja át az adatokat, így az 
utolsó másolás is elmarad. 

Mivel az adatokat a lemezről be kell olvasni a memóriába, majd 
ki kell küldeni a hálózatra, néhányan talán nehezményezik, 
hogy nem igazi nullmásolást végzünk. Ez részben így is van, de 
az operációs rendszer szempontjából elértük a célunkat, 
ugyanis az adatokat már nem többszörözzük rendszermag át- 
meneti tárak között. Nullmásolás használatakor nemcsak a ke- 
vesebb másolás által javítunk a teljesítményen, hanem kevesebb 
környezetváltásra van szükség, nem kavarjuk össze a procesz- 
szor gyorsítótárát, és ellenőrző összegeket sem kell számítani. 
Most, hogy tisztában vagyunk a nullmásolás lényegével, a 
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gyakorlatban is alkalmazzuk elméleti tudásunkat. A teljes for- 
ráskódot a 3 http:/www.xalien.org/articles/source/sfl-src.tgz 
címen vagy a 45. CD Magazin/Zero Copy könytárában érheted 
el. Kicsomagolni úgy tudod, hogy kiadod a tar --zxvf sfl- 
src.tgz parancsot. A make paranccsal egyrészt lefordíthatod 
a kódot, másrészt egy véletlenszerű tartalommal feltöltött, 
data.bin nevű adatállományt is létrehozhatsz. 

Lássuk a kódot, a fejlécfájlokkal kezdve: 


/: sfl.c sendfile pgldaprogram 
Dragan Stancevic visitorgxalien.org 09-09-2002 
fejldc neve f ggvÖny/vEltoz 


További érdekességek 


Forráskód és használat 

A teljes forráskódot a 45. CD Magazin/Zero Copy könyv- 
tárában találod. A tar --zxvf sf1-src.tgz paranccsal 
bonthatod ki, majd a make paranccsal hozhatod létre a 
futtatható állományt. A könyvtárban egy síf1 nevű futtat- 
ható fájlnak kell létrejönnie, átadott értékek nélkül indítva 
a program rövid használati útmutatót jelenít meg. Mind a 
kiszolgáló-, mind az ügyféloldalon meg kell adnod a 
kiszolgáló IP-címét. 


Példa: 

Küldő oldal: 

visitor Dxalien-saucer:—/sfl-sre5 ./sfl s 10.0.0.2 
Server binding to [10.0.0.2] 

Server sent 10240 bytes. 

visitor Doxalien-saucer: —/sfl-sre 5 


Fogadó oldal: 
visitorDearth:—/sfl-sre5s ./sfl r 10.0.0.2 
Client connecting to [10.0.0.2] 

Client received 10240 bytes. 
visitorVDearth: —/sfl-sre 5 


Megjegyzések a kódhoz 

1. Én az 1033-mas kaput használtam, ha te a saját 
rendszereden ezt más célra használod, válassz másikat. 

2. A példaprogram egyszerűsítése és rövidítése 
érdekében a 10 KB-os átmeneti tárat a verembe raktam. 
Saját kódodban a mal1oc függvénnyel foglalhatsz 
átmeneti tárakat. 

3. A cikkben szereplő program lerövidítése érdekében 
elhagytam a close rendszerhívás visszatérési 
értékének vizsgálatát. Egy valódi programban 
természetesen el kell végezned az ellenőrzést. 


Példák 

Ha mélyebben is meg szeretnél ismerkedni a sendfile 
rendszerhívás használatával, pillants bele néhány olyan 
alkalmazásba, amelyik használja: 

Apache 3 http://www.apache.org 

Samba 3 http://www.samba.org 

Mozilla 8 http://www.mozilla.org 

Pure-FTPd 5 http://pureftpd.sf.net 

Ha érdekel a rendszermag fájlbérlési szolgáltatása, 

nézz bele a Samba forráskódjába, az smbd/oplock linux.c 
fájlba. 


Hinclude cstdio.hsz 7k Brintf, 

perror Fr/ 
Hinclude -fentl.hszs /F open Y/ 
Hinclude zunistd.hsz /tr close §/ 
Hinclude cerrno.hsz /t errno §/ 
Hinclude cstring.hzs /:r memset F/ 
Hinclude csys/socket.h: /r socket F/ 
Hinclude -cnetinet/in.hsz /: sockaddr in F/ 
Hinclude csys/sendfile.h: /r sendfile F/ 
Hinclude carpa/inet.h: /: inet addr r/ 


tdefine BUFF SIZE (10r1024) /r a tmp Etmeneti 


tEr mÖrete F/ 


Az alapvető foglalatműveletekhez szükséges 
csys/socket.h: és c-netinet/in.h: mellett a sendfile 
rendszerhívás törzstípusát is meg kell adnunk. Ezt a 
csys/sendfile.h: server jelzőjében találjuk: 


/F k ld nk vagy fogadunk §/ 
if(argv[1] [0] -- "s") is servert; 


/F le r k megnyitEsa F/ 
sd z socket(iBF INET, SOCK STREAM, 0); 
it(18. server) fd c öpenl"data.bin", 0 RDÖONLY) ; 


Ugyanaz a program kiszolgálóként (küldőként) és ügyfélként 
(fogadóként) is használható. Ellenőrizni kell a megfelelő 
parancssori átadott értéket, majd -— szükség szerint — az 

is server jelzőt beállítva küldő módba válthatunk. Az INET 
protokollcsalád egy folyamfoglalatát is megnyitjuk. Mivel a 
program most kiszolgálóként üzemel, adatokat kell küldenie 
az ügyfeleknek, ezért az adatállományt is megnyitjuk. Az ada- 
tok küldésére a sendfile rendszerhívást használjuk, így 
nincs szükség a fájl tartalmának beolvasására és a saját prog- 
ramunk átmeneti tárában történő tárolására. A kiszolgáló címe: 


/:r a mem ria t rlGse F/ 
memset (ésa, 0, sizeof(struct sockaddr in) ) ; 


/: az adatszerkezet kezdi OrtÖkadfsa F/ 
Sa. S10n family s PF INET; 

S4á.S11 port s Htónsíi1033) ; 

84. 811n addr.8 addr zs inet addrlargv [2] ) ; 


Töröljük a kiszolgáló címét tároló adatszerkezet tartalmát, 
majd adjuk meg a protokollcsaládot, a kaput és a kiszolgáló 
IP-címét; az utóbbit a program átadott értékként kapja meg. 
A kapu bedrótozott módon az egyébként használaton kívüli 
1033-mas lesz. Azért ez, mert e kaputartomány használatához 
az adott rendszeren már nincs szükség rendszergazdai 
jogosultságra. 

A kiszolgálói ág: 


if(is server) ( 


int client; /r ej gyfOlfoglalat F/ 
printf("A kiszolg£l a lIs$8s] kaput 
shasznElja.Wn", argv [2] ) ; 


if(bind(sd, (struct sockaddr ") §sa, 
ssizeof(sa)) c 0)( 
perror ( "bind" ) ; 


exit (errno) ; 
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Kiszolgálóként címet kell rendelnünk a foglalat leírójához. 
Ezt a bind rendszerhívással tehetjük meg, amely a foglalat 
leírójához (sd) egy kiszolgálócímet rendel (sa): 


if(listen(sd,1) z 0)( 
perror ("listen") ; 
exit (errno) ; 


] 


Mivel folyamfoglalatot használunk, valahogy ki kell 
nyilvánítanunk kapcsolatok fogadására irányuló szán- 
dékunkat, és meg kell adnunk a kapcsolati várólista méretét 
is. A kapcsolati várólista (backlog gueue) hosszát 1-re állí- 
tottam, de a már felépült kapcsolatok fogadása érdekében 
ennél nagyobb értéket is meg szoktak adni. A rendszermag 
régebbi változatainál a kapcsolati várólista segítségével 
előzték meg a syn-elárasztásos támadásokat. Mivel a listen 
rendszerhívás időközben módosult, és csak a felépült 
kapcsolatok beállításait adja meg, a kapcsolati várólistára 
többé nincs szükség; pontosabban a rendszermag 

tcp max syn backlog beállítása gondoskodik arról, 
hogy megelőzze a rendszer ellen irányuló syn-elárasztásos 
támadásokat: 


if((client - accept(sd, NULL, NULL)) c 0( 
perror("accept h vEsSs"); 
exit (errno) ; 


] 


Az accept rendszerhívás a függőben lévő kapcsolatok várólis- 
tájának első kérését feldolgozva új csatlakoztatott foglalatot 
hoz létre. A hívás visszatérési értéke az új kapcsolat leírója. 
Ezzel a foglalat alkalmassá vált a read, write, poll és 
select rendszerhívások használatára: 
if((cnt - sendfile(client, fd, 5off, 
BUFF SIZE)) c 0) ( 
perror("sendfile h vES"); 
exit (errno) ; 
] 
print("A kiszolgAl 
SENTE ) s 
close(client) ; 


szd bEjtot k ld tt el.n", 


A foglalatleíró használatával létrejött egy kapcsolat, tehát meg- 
kezdhetjük az adatok továbbítását a távoli rendszerre. Erre a 
sendfile rendszerhívást használjuk, amelynek törzstípusa 
Linux alatt a következő: 


extern ssize t 
sendfile (int — oüt fd, 
s xoffset, 


int . ín td; :8Ef € 
size t . count) —— THROW; 


Az első két átadott érték fájlleíró. A harmadik az eltolás, 

ez adja meg, hogy a sendfile honnan kezdje meg az 
adatok küldését. A negyedik a küldeni kívánt bájtok száma. 
Ahhoz, hogy a sendfile nullmásolással továbbítsa az 
adatokat, a hálózati csatolónak támogatnia kell az adatgyűj- 
tést. Azoknál a protokolloknál, amelyek ellenőrző összegeket 
számítanak - ilyen többek közt a ICP és az UDP -, az 
ellenőrző összegeket is ki kell tudnod számítani. Szerencsére 
akkor sem kell lemondanod a sendfile használatáról, ha 

a hálózati csatolód régi, és nem támogatja ezeket a szolgál- 
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tatásokat. A különbség mindössze annyi, hogy a rendszer- 
mag ekkor küldés előtt összerendezi az átmeneti tárakat. 


Hordozhatósági kérdések 

A sendfile rendszerhívással általános esetben az a baj, hogy 
— az open hívással ellentétben - nincs szabványos megvaló- 
sítása. A Linux, Solaris és HP-UX alatti megvalósítások kismér- 
tékben eltérnek egymástól, és ez gondot jelenthet a hálózati 
alkalmazásaikban a nullmásolási lehetőséget kihasználni 
kívánó fejlesztőknek. 

Az egyik eltérés a megvalósítások között az, hogy a linuxos két 
fájlleíró között teszi lehetővé az adatátvitelt, azaz fájl-fájl és 
fájl-foglalat párosításokat is kezel, míg a HP-UX és a Solaris 
megvalósítás csak fájl-foglalat átvitelekhez használható. 

A másik különbség az, hogy Linux alatt nem lehet vektoros 
átviteleket végezni. A Solaris és a HP-UX sendfile megvaló- 
sítása külön átadott értékek használatával szükségtelenné teszi 
az átvivendő adatokhoz csatolt fejlécek miatt elvégzendő több- 
letmunkát. 


Előre tekintve 

A Linux alatti nullmásolás megvalósítása még nem fejeződött 
be, és a közeljövőben valószínűleg módosulni fog a szolgáltatás 
működése - várhatóan újabb lehetőségekkel bővül. Például 

a sendfile nem támogatja a vektoros átviteleket, és a kiszol- 
gálók — mint az Apache vagy a Samba - több, TCP CORK jel- 
zővel jelölt sendfile hívást kénytelenek végrehajtani. Ez 

a jelző arról tudósítja a rendszert, hogy újabb sendfile 
hívásokkal további adatokat akarunk küldeni. A TCP CORK 
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azonban nem fér össze a TCP NODELAY jelzővel, illetve akkor 
is használjuk, ha az adatokhoz fejlécet akarunk csatolni. 
Nagyszerű példája ez annak, amikor a vektoros átvitellel több 
sendfile hívást ki lehetne váltani, illetve a jelenlegi megva- 
lósítással járó késleltetéseket el lehetne hagyni. 

Ugyancsak kellemetlen megkötés, hogy a jelenlegi sendfile 
csak 2 GB-nál kisebb fájlok továbbítására használható. Manap- 
ság egyáltalán nem szokatlanok az ekkora állományok, viszont 
ekkora adatmennyiséget megkettőzni küldés közben több mint 
kellemetlen. Mivel ilyen esetben az mmap és a sendfile 
egyaránt használhatatlanok, egy sendfile64 megvalósítás 
igencsak jól jönne az újabb rendszermagváltozatokban. 


Összegzés 

Korlátai ellenére a nullmásolás hasznos szolgáltatás, és 
remélem, írásomban elegendő adatot találtál ahhoz, hogy te is 
elkezdd használni a saját programjaidban. Ha érdekel a téma, 
olvasd el a hamarosan megjelenő második részt, amelyben 

a rendszermag szempontjából járom körül a nullmásolás 
kérdéskörét. 


Linux Journal 2008. január, 103. szám 


Dragan Stancevic 

Húszas éveinek végén Járó rendszermag- és eszközfejlesztő. 
Szakmája szerint programmérnök, de az alkalmazott fizika Is 
érdekli, szabadidejében különlegesen magas elektromos 
feszültségekkel szeret kísérletezni. 
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Gyorsrendezés elemzése DDD segítségével 


Ismerkedjünk meg egy jó hibakeresővel, és értsük meg a gyorsrendezést! 





rendezés a számítógépek által az egyik leggyakrabban 
AA végrehajtott művelet, és erre a gyorsrendezés az 

egyik leghatékonyabb módszer. Írásomban egyrészt 
bemutatom, mennyire hasznos lehet egy grafikus hibakereső, 
másrészt ismertetem a gyorsrendezés elvét. 

A DDD (Data Display Debugger) egy szabad grafikus felület, 

amely számos hibakereső felett használható. A továbbiakban 

a DDD segítségével vizsgáljuk meg a gyorsrendezés egyik 

egyszerű C-megvalósítását. 

Először is be kell szerezni a DDD egy példányát, majd telepí- 

teni kell. Bináris és forráscsomagokat egyaránt találhatunk, 

ebben RPM alapú terjesztések esetében az rpmfind.net lehet 

a segítségünkre, Debian-csomagokat pedig a debian.org segít- 

ségével keríthetünk. Cikkem írásakor 3.3.1-es DDD-t és Red 

Hat 7.3-as terjesztést használtam. A továbbiak során három 

dolgot feltételezünk: 

1. GNU/Linux alapú számítógéppel rendelkezünk, ami be 
van kapcsolva; 

2. ismerjük az alapvető C-fogalmakat, mint tömbök, ciklusok 
és önhívás (recursion); 

3. megfelelő C-fordítóval rendelkezünk, például a GNU GCC-vel. 
Még ha fogalmad sincs a programozásról, próbáld meg átta- 
nulmányozni a kódot - hasznát látod a későbbiek folyamán. 

C. A. R. Hoare 1962-ben vázolta fel a gyorsrendezés algoritmu- 

sát, amit negyven év elteltével még mindig széles körben hasz- 

nálnak. A gyorsrendezés talán , oszd meg és uralkodj" felfogása 
miatt lett , gyors", mivel a nagyobb elemeket kisebbekre osztva 
szükségtelenné teszi nagy számú összehasonlítás elvégzését. 

Ellentéte például a legkisebb kiválasztásának elvére épülő 

rendezés, amely minden elemet összehasonlít az összes többi- 

vel. lermészetesen ez nem feltétlenül jelenti azt, hogy a gyors- 
rendezés mindig gyorsabb vagy ez a legjobb rendezési mód, 
egyszerűen csak jó ismerni. Az írásomban szereplő megvalósí- 
tás nem javított és nem bővíthető, kizárólag egész számokból 
álló tönmbökkel működik. 

A kód jelentős része Brian W. Kernighan és Rob Pike ,Ihe 

Practice of Programming" című művéből származik. 


cstdio.hsz 
astdlib.hsz 
zxtime.h: 


Hinclude 
Hinclude 
Hinclude 


/F Brian W. Kernighan Os Rob Pike The 
Practice of Programming 
x c mis k nyvőnek 32-34. 
47 


oldalzgr 1 


felcserőlgGse F/ 
int JJ) 


/: sw ap: v[lil Os v[j] 
void swaplint vIl; int 1; 


( 


int. em; 
tűb a viil:; 
SIET s vijls 
v.lil zs tmp: 
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] 


/: guicksort: a v[0]..vIn-1] 
sorrendbe rendezőse F/ 


elemek n vekvi 


void gülöksörtlint vil, int mm) 
int i - 0, last - 0; 
if (nca-1) 
return; /t semmit nem csinEl r/ 


o 


rand() 5 n); 
elem mozgat£sa v[01]-ba F/ 


swap(v, 0, 
/r az elvXglaszt 


for(i - 1; i ca n, 1141) /r kettgosztEs F/ 
it 4 vlil ec vIO0[] 
swap(v, d4tilast, i); 
swap(v, 0, last); 


/:r az elvElaszt elem visszakfll tX£sa F/ 


guicksort(v, last); 
/r a kisebb Görtőkek rendezőse F/ 


guicksort(vilastr1, n-last-1) ; 
/F a nagyobb örtGkek rendezőse "/ 


] 


void print array(const int array[], int elems) 


í 
int i; 
printriti1) s 


i ca elems; 1-7) 
preinttrt"zd. 1, 


for(i - 0; 
array l[i] ) ; 


printé ("rat z 


] 


Hdefine NUM 9 


int main(void) 
int arr[NUM] - 
ST 6; d:2 ; 41, 18 34 41, 1.6; 15, 19) 


/: megjegyzősbe raktuk, hogy elire 1lEtni 
lehessen a rendezős menetgt 
srand( (unsigned int) time(NULL) ); "/ 


print array(arr, NUM) ; 
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guicksort (arr, NUM), ; 
print array(arr, NUM) ; 
return EBXAII SUCCESS; 


] 


Lépésről lépésre 

Mentsd a kódot egy easy gsort.c nevű állományba. Ezután 
fordítsd le: 

$ gcc -Wall -pedantic -ansi -o gsortof -g 
—edsy gsort.c 


A GCC-nek megadott kapcsolók közül a -g a legfontosabb, 
amely hibakeresési hivatkozással (symbol) látja el a kódot. 


Próbáld lefuttatni a programot, így kiderül, minden rendben van-e: 
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$§. /dsortot 
( § 12 4 18 3 27 16 15 19 1 
(3 4 6 12 15 16 18 19 27 ) 


A kimenet első sora a rendezetlen tömb, a másik pedig a gyors- 
rendezés futtatása utáni helyzetet tükrözi. Vajon hogyan mű- 
ködik? Hívjuk segítségül új barátunkat, a DDD-t: 


$ ddd asortof 


Ezzel elindul a DDD. Zárd be a felbukkanó Tipp vagy Névjegy 
ablakot, és az első ábrán láthatóhoz hasonlók tárulnak eléd. 
Nem árt, ha bekapcsolod a sorok számozását. Jelöld be a 
Display Source Line Numbers (Forráskódsorok sorszámának 
megjelenítése) négyzetet, ezt az Edit, Preferences, Source 
(Szerkesztés, Beállítások, Forrás) menüpont alatt találod. 
Most már csak egy töréspontot kell hozzáadnunk, és indulhat 
a hibakeresés. 

Jelöld ki a semmittevő sort úgy, hogy az oldalt megjelenő 
sorszámára kattintasz. Ezután a () gombnál kattints a Set/Delete 
Breakpoint (Töréspont hozzáadása törlése) parancsra, és a 
parancsablakban kattints a Run (Futtatás) gombra. 

Ekkor egy piros stopjel jelenik meg a töréspontot tartalmazó 
sorban, illetve egy zöld nyíl is felbukkan ugyanitt (ez jelzi az 
éppen végrehajtandó kódrészletet). Jelenítsünk meg néhány 
belső adatot a DDD segítségével. Először válaszd a Data, 
Display Local Variables (Adat, Helyi változók megjelenítése) 
menüpontot. A második legyen a Data, Display Arguments 
(Adat, Átadott értékek megjelenítése), majd következzen a 
Status, Backtrace (Állapot, Visszakövetés). Végül gépeld be a 
graphdisplay v [0] en parancsot a konzolablakba, majd 
nyomd le az ENTER billentyűt. Ekkor felbukkannak a v [] 
tömb elemei, 0-tól n-ig (lásd a második ábrát). 


Vajon mi történik odabent? 

A töréspontot úgy adtuk meg, hogy ha az átadott tömb csak 
egyetlen elemet tartalmaz vagy üres, akkor önhívással folyik, 
a vizsgálat feltétlenül szükséges, hiszen ha egy vagy nulla 
elemet adunk át, akkor le kell állítani az önhívást (erről később 
még lesz szó). 

A vizsgálat után fogunk egy elválasztó elemet, és a tömb ele- 
jére mozgatjuk. Kattints a Next (Iovább) gombra, míg a zöld 
nyíl a swap függvény hívásáig nem ugrik. A Next gombra 
kattintva sorról sorra haladhatsz, az alfüggvények meghívása 
nélkül; a Step (Lépés) gombra kattintva viszont az alfüggvé- 
nyekbe is belépsz. Kattints még egyszer a Next (Iovább) 
gombra, és figyeld, hogy mi történik. 

Az én gépem felcserélte v[] nulladik és első elemét, vagyis 

a rand() $ n hívás 1-et adott vissza. Ha többször is megvizs- 
gálod a programot, észre fogod venni, hogy a rand() $n 
mindig 1-et ad. Véletlen létére elég egyhangú, nemde? Ebben 
a példában az srand() hívás megjegyzésbe tételével elmarad 
az álvéletlenszám-generátor megbolygatása, ezért a rand ( ) 
mindig megjósolható eredményt ad. 

Az így meghatározott elválasztó elemet használjuk fel arra, 
hogy a számokat nála kisebbekre és nagyobbakra osszuk. Az 
elválasztó elem azért került a vI0] helyre, mert amíg a teljes 
tömböt át nem vizsgáltuk, addig nem ismerjük a pontos helyét. 
A kettéosztást végző ciklus végiglépked a tömb összes elemén, 
és összehasonlítja őket az elválasztó elemmel; ez esetemben 

a 12 volt. A last elem növelése előzetesen történik (preincre- 


ment), így az egyes cellában lévő elemet önmagával cseréljük fel. 
Igen, én is tudom, feleslegesen. Az algoritmus hatékonyabbá 
tétele kellemes feladat az önmaguk sanyargatását élvező olvasók 
számára. Még meg akartam említeni, hogy az Interrupt (Meg- 
szakítás) gombra kattintva a program futását bármikor meg- 
szakíthatjuk, majd a Run (Futtatás) gombbal újraindíthatjuk. 
Kattintgass a Next (lIovább) gombra, amíg az i értéke 3, a 
last változóé pedig 2 lesz; ehhez figyeld a Locals (Helyi 
változók) ablak tartalmát. A kettéosztó hurok if elágazása 
most a 18-at és a 12-t hasonlítja össze. A vizsgálat sikertelenül 
zárul (kattints), ezért az i-t növeljük (kattints), a last 

változó értéke 2 marad. 

Maradjunk szoros kapcsolatban a Next gombbal, amíg az i 
értéke 9 nem lesz. A tömb most a következőképpen néz ki: 


lt 12 6 4 3 18 27 16 15 159. ) 


Újra kattintás, és a 12, amely eddig a kisebb számok között 
tévelygett, helyet cserél a 3-mal. 

Miután az elválasztó elem az eredeti helyére kerül, önhívással 
újra meghívjuk a guicksort függvényt, miközben átadunk 
neki egy mutatót v [01] -ra, és közöljük vele, hogy egy 
háromelemű - a kisebb számokat tartalmazó - tömböt fog 
kapni. Ezután újra meghívjuk, de ezúttal v [4] -re mutatunk és 
ötelemű tömböt adunk neki, most a nagyobb számokkal. Újra 
és újra meghívjuk a guicksort függvényt, egészen addig, 
ameddig az átadott tömbökben csupán egyetlen elem marad. 
Ekkor megindul a hívások visszatérése - elsőként az utolsó -, 
és mire a main függvénybe érkezünk, rendezett tömböt 
kapunk. Kifújhatjuk magunkat! 


Ami jól jöhet 
Ha elég mélyen elmerülsz az önhívású guicksort hívások 
mocsarában, egy ponton a v [0] en ablak el fog tűnni. Egy 
megfelelő gombot létrehozva egy pillanat alatt újra 
előcsalogathatod. Gombot a Commands, Edit Buttons..., Data 
Buttons (Parancsok, Gombok szerkesztése, Adatgombok) 
menüpont segítségével hozhatsz létre. A szövegbeviteli mezőbe 
gépeld be az alábbiakat: 


graph display v[IO0]aen // Varray 


Egy Varray nevű gombnak kell megjelennie a Data (Adat) 
ablak tetején. Ha a vI0] an ablak olvas (letiltódik), kattints 
rá az egér jobb gombjával, és válaszd az Undisplay (Elrejtés) 
parancsot. Ezután kattints a Varray gombra. Ha az ablak 


továbbra sem jelenik meg, próbálj néhányszor rákattintani 
a Next ( lovább) gombra, és próbálkozz újra. 


A múlt bűvöletében 

Korábban bekapcsoltattam veled a Backtrace (Visszakövetés) 
ablakot. Miközben guicksort () hívások tornyosulnak 
feletted, a Backtrace ablak soraira kattintva érdekes lehet 
belekukkantani a verem tartalmába. Láthatod, hogyan jutottál 
el a pillanatnyi függvényhívási környezethez, és a futás más 
időpontjaiban milyen adatok voltak a veremben. 


A gépi kód ablak 

Ha eléggé elkábultál, tégy egy kísérletet a View, Machine Code 
(Nézet, Gépi kód) paranccsal, amellyel megjelenítheted az 
éppen folyó műveletek assembly utasításait. 


További érdekes algoritmusok és adatszerkezetek 
A DDD csodálatos látvány, amikor láncolt listákat vagy más 
adatszerkezeteket jelenít meg. Próbáld ki! 


Linux Journal 2003. január, 105. szám 


Adam Monsen 

Érdeklődő természetű orvostanhallgató, jelenleg 
a washingtoni classmates.com kezdeményezés 
programozója. Szeret zongorázni, szörfözni, 
amatőr artista. GNU/Linux Red Hat 7.3 alapú 
gépén Perl, Java és néha C nyelven kódolgat. 
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Linux alapú gőzturbina-próbapad 


Vajon a szentpétervári Központi Kazán és lIurbina Intézet hogyan garantálja 
a biztonságot és a pontos vezérlést az erőműturbinák kipróbálásakor? 





nnak ellenére, hogy a matema- 
tikai modellek és a számítógé- 
pek teljesítményének elké- 


pesztő növekedése révén szinte bármit 
lehet szimulálni vagy ki lehet számolni, 
bizonyos területeken a gyakorlati 
tapasztalatok nem vesztettek a jelentő- 
ségükből, és nem pótolhatók számító- 
gépes modellezéssel. 

Az ilyen területek egyike az alacsony 
nyomású gőzturbinák (LPMT) tervezése. 
Az LPMI-k fontos részei a gőz vagy 
kombinált gáz-gőzciklusban üzemelő 
erőműveknek, és az ilyen erőművek 
által előállított energiának akár a 20 szá- 
zalékát is adhatják. A nagy- és közepes 
nyomású turbinákkal ellentétben — ame- 
lyeknél a gőz jól ismert jellemzőkkel 
rendelkezik -—, az LPMI-k strukturálat- 
lan, nem szimmetrikus, nedves gőzzel 
dolgoznak. Az ilyen jellegű áramlásokra 
jelenleg még nem léteznek teljesen meg- 
bízható matematikai modellek. A valós 
kísérletek nélkülözhetetlenek a turbinák 
áramlási útvonalainak tervezéséhez, 
illetve a turbinák számítógépes modell- 
jeinek továbbfejlesztéséhez. 

Az egész világon mindössze néhány 
próbapad létezik. Az egyik Szentpéter- 
váron található és a Központi Kazán és 
Turbina Intézet tulajdona — jómagam hét 
éve dolgozom itt. Képzelj el egy 18 mé- 
ter magas, 700 négyzetméter alapterü- 
letű, csövekkel, vezetékekkel és mérőbe- 
rendezésekkel teli csarnokot. Középen 
egy gigászi építmény áll, ez a modell- 
turbina háza, belőle két hatalmas cső 
vezet ki. A próbák idején óránként 

40 tonna friss gőzt használ el, amelynek 
nyomása 30 bar, a hőmérséklete 4007C a 
próbapad bevezetésein, körülbelül 4 bar 
és 2007C a modellturbina bevezetésén, 

a kivezetéseken pedig mindössze 

30 mbar nyomáson távozik. 


A számítógépes 

és mérőberendezések felépítése 

Az Alstom Powerrel indított közös , lanja" 

tervezetünk keretében megújítottuk a 

próbapad számítógépes háttérrendszerét. 

A rendszer most három részből áll: 

1. Egy nagy pontosságú tudományos 
mérőrendszerből, ami az áramlási 
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útvonalak adatait gyűjti (a továbbiak- 
ban DAS-Flow). 

2. Egy technológiai mérőrendszerből, 
ami a működtető személyzet számára 
gyűjti az adatokat (a továbbiakban 
DASOP). 

3. A kutatók és mérnökök által használt 
munkaállomásokból. 

A DAS-Flow rendszert eredetileg főként 

az ügyfeleink adták. Az áramlási útvo- 

nalon több mint 200 helyen méri a nyo- 
mást, illetve ötven helyen a hőmérsék- 
letet. A rendszer egy különálló részével, 

12 darab mozgatható érzékelővel a nyo- 

más turbinán belüli eloszlását is nyomon 

követhetjük. Minden érzékelő tengely- 
irányban mozgatható, illetve forgatható 

— erről távvezérelhető léptetőmotorok 

gondoskodnak. A nyomásmérésekhez 

a PSI, Inc. PSI-9000 sorozatú érzékelőit 

használjuk. Ezek rendkívül pontos ada- 

tokat szolgáltatnak: az alapnyomások 
esetében 001, a többinél 0,1 százalékos 
pontossággal mérnek. A rendszer csak 

a megadott időpontokban, üzembiztos 

állapot mellett végez méréseket, dinami- 

kus nyomások mérésére alkalmatlan. 

A DASOP rendszert magunk építettük, 

a pad próbák alatti folyamatos vezérlé- 

sére alakítottuk ki. Valós idejű módban 

működik, az adatokat több mint 150 

nyomást, hőmérsékletet, fordulatszámot 

és rezgést mérő érzékelőtől gyűjti be. 

Az adatokat két képernyőn jeleníti meg 

a működtető személyzet számára, illetve 

egy soros terminál is helyet kapott a 

vezérlőhelyiségben. Segítségével a sze- 

mélyzet figyelemmel követheti a pró- 
bapad víz-, gőz- és olajkezelő rendsze- 
reinek pillanatnyi állapotát. A DASOP 
biztonsági ellenőrzéseket is végez, illetve 
figyelmeztetési és vészjelző határérté- 
keket is kezel. 

Számítógépeink - az egy darab IBM RISC 

munkaállomástól eltekintve - teljesen 

átlagos személyi számítógépek, procesz- 
szoruk a 386-ostól a Pentium 4-ig és az 

Athlonig terjedő teljes vonalat lefedi. 


Miért éppen Linux? 
Amikor -— 1995-ben - bekapcsolódtam a 
lanja tervezetbe, már jókora tapasztala- 


at 


tot szereztem adatgyűjtő és -értékelő 





DASOP adatmegjelenítő modulok 


rendszerek építésében a Digital PDP-11- 

es gépek RI-11 vagy RSX-11 operációs 

rendszert futtató orosz másolataival. 

Mike, a testvérem 1994 körül vette meg 

nekem az első Linux-terjesztésemet, ami 

egy -— ha jól emlékszem - nagyjából 
0.99-es Linux-rendszermagra épülő 

Slackware volt. Hamar rájöttem, hogy 

szinte minden feladatomat meg tudom 

oldani a hasonló programok forrásának 
tanulmányozásával, illetve kiinduló- 
pontként használva őket. Első adatgyűj- 
tő rendszeremmel 1994-ben készültem 
el. Az ncurses volt az alapja, korábbi 
munkahelyemen azóta is működik, 
hozzá sem kellett nyúlnom. 

A Tanja tervezet kezdetekor csak az ügy- 

feleink által adott DAS-Flow rendszer állt 

rendelkezésünkre. Operációs rendszerek 
sokasága volt itt, egyaránt volt benne 

MS-DOS, Microsoft Windows 3.11 és NI, 

ONX és AIX. Hogy valami jót is mond- 

jak: a számítógépek TCP/IP alapú helyi 

hálózaton át kapcsolódtak egymáshoz. 

A teljes rendszer fejlesztési irányvonalán 

gondolkodva, illetve az addigi tapaszta- 

lataimra alapozva úgy döntöttünk, hogy 

technológiai mérőrendszerünk, a 

DASOBP illetve hálózatunk központi 

részének az alapja a Linux lesz. A fő 

okok a következők voltak: 

e Használatra kész alkalmazások szé- 
les választéka állt rendelkezésükre, 
amelyeknek tanulmányozás céljából 
a forráskódját is el lehetett érni, 
illetve alapul lehetett használni őket 
további programok fejlesztéséhez. 

e . Megbízható működés olcsó személyi 
számítógépeken - esetünkben ez a 
legfontosabb követelmények egyike. 


e — Költségvetésünk szűkös, így a Linux 
ingyenessége fontos szempont volt. 
Mivel dolgozunk most? Számítógépes 
rendszerünk most hat linuxos PC köré 
épül. Több mint hat év alatt soha nem 
volt meghibásodás, a gépek éveken át 
folyamatosan üzemeltek, újraindítás 
csak két okból fordul elő: a gépek bőví- 
tésekor, illetve a hosszabb áramkimara- 
dások alkalmával, amikor már a szünet- 
mentes tápegységek is kifulladtak. 
Red Hat terjesztéssel kezdtünk. Később 
a KSI nevű, orosz nyelvre honosított, 
RPM alapú terjesztést kezdtük el hasz- 
nálni, tavaly pedig a Debian jutott sze- 
rephez. Jelenleg a központi kiszolgálónk 
és az én fejlesztői gépem Debian/Woody 
rendszert futtat. Nagyon elégedettek 
vagyunk a Debiannal, és úgy vélem, 
idén az összes linuxos gépünkre ez 
fog kerülni. 


A hálózat 

Minden számítógépünk rendelkezik 
helyi hálózati kapcsolattal; a hálózat 
három részből áll. Az első szegmensen 
a DAS-Flow számítógépek, a másodikon 
a DASOP és az irodai számítógépek ta- 
lálhatók, a harmadik pedig a külvilág 
felé vezet egy bérelt vonalon keresztül. 
A harmadik szegmensen csupán egy szá- 
mítógép van, ezt használjuk átjáróként 
az Internet felé, illetve ÍP Chains alapú 
tűzfal és levelezőkiszolgáló is fut rajta. 
A hálózat , közepén" helyezkedik el a 
központi kiszolgálónk. Fájl- és nyomta- 
tókiszolgálóként szolgál a többi számí- 
tógép számára, de a legfőbb feladata 
nem ez. A próbák alkalmával nagy 
mennyiségű adatot gyűjtünk össze. 
Ezek az adatok -— nyers formában — 
mérési eredményekként, illetve később 
kiértékelt értékekként önműködően 
bekerülnek egy MySOL-adatbázisba. 
Egy Apache webkiszolgáló HIIPS pro- 
tokollon keresztül az összes felhasználó 
számára — a kutatóktól kezdve egészen 
az ügyfelekig — sokoldalú felületet 
biztosít az adatbázishoz. 

A bejegyzett felhasználóknak csak egy 
böngészőre van szükségük az adatbázis 
eléréséhez, az adatok közötti kereséshez 
és az eredmény grafikus vagy szöveges 
formában való megjelenítéséhez. 

A rendszer PNG, CGM és PDF formá- 
tumokat használ. Az adatok megjelení- 
tésére szolgáló oldalakat elsősorban 

—- Apache mod php modulként futó — 
PHP segítségével hozzuk létre. Szinte 
az összes grafikont valós időben állítjuk 
elő, gnuplot és Perl CGI-parancsfájlok 
segítségével, amelyek kiválasztják a 
megfelelő értékeket az adatbázisból, át- 
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adják őket a gnuplot-nak, majd a létre- 
jött képet továbbítják az Apache felé. 
Több mint ötven különböző CGI-pa- 
rancsfájlt írtunk, így a felhasználók ren- 
geteg különféle megjelenítési módot 
használhatnak, illetve választási lehető- 
ségük gyakorlatilag mindenre kiterjed: 
mely értékeket szeretnénk megjelení- 
teni, mik legyenek a keresési feltételek, 
milyen jellemzőket akarnak kirajzol- 
tatni, önműködő vagy kézi legyen-e 

a tengelyek méretezése, milyen legyen 
a simítás és a közelítés stb. 

Szeretném külön kiemelni a gnuplot- 
nak a munkánkban betöltött szerepét. 
Számomra ez a legnagyszerűbb tudomá- 
nyos rajzolóalkalmazások egyike, hatal- 
mas tudással és kimeneti formátumok 
széles választékával. A kiválóan terve- 
zett JpGraph PRHP osztályokat is hasz- 
nálom bizonyos megjelenítési felada- 
tokra, főleg a gyorskeresések eredmé- 
nyének kirajzolására. 

Az általunk kifejlesztett Programrend- 
szer másik fontos része a DASOP tech- 
nológiai adatgyűjtő rendszer. Moduláris 
felépítésű: adatgyűjtő, kiértékelő, 
foglalatalapú adatcsere és alkalmazói 
modulokat tartalmaz. 

Az adatgyűjtő modul egy a számítógép- 
hez R5S232 felületen csatlakozó progra- 
mozható adatvezérlővel (Programmable 
Data Controller — PDC) működik együtt. 
Másodpercenként 150 értéket vesz át a 
PDC-től, illetve szükség esetén digitális 
be- és kiviteli műveleteket végez vele. 
Minden mérési eredmény egy osztott 
memúóriaterületre kerül, egy kétdimen- 
ziós tömbbe, ahol az egyes oszlopok 
nyers formában az összes jellemző érté- 
két tartalmazzák. Az oszlopok száma 
rögzített, így visszamenőleg mindig 
adott számú adatsor áll rendelkezésre 

a memóriában. 

A kiértékelő modul, amely jelzők segít- 
ségével marad összhangban az adat- 
gyűjtő modulokkal, beolvassa az utolsó 
mérési eredménysort az osztott memó- 
riából, elvégez néhány azonnali számí- 
tást, majd a kiértékelt adatokat ugyan- 
abba az oszlopba írja vissza, egyben meg 
is hosszabbítva azt. 

A foglalatalapú adatcseremodul a távoli 
alkalmazói modulok számára biztosítja 
a hozzáférést a megosztott memóriate- 
rülethez. Alkalmazói modulból sokféle 
létezik. Egyesek helyben, a mért és 
kiértékelt adatokat tartalmazó osztott 
memúóriarész közvetlen elérésével futtat- 
hatók, mások távoli memória-hozzá- 
férését az adatcseremodul teszi lehetővé. 
Az alkalmazói modulok között adatnap- 
lózó, biztonsági vezérlő és adatmeg- 





jelenítő modulokat találunk. 

Az adatmegjelenítő modulok valós idő- 
ben, különféle szempontok szerint jele- 
nítik meg az adatokat. Néhány ábrázo- 
lási példa: az értékek változása az idő 
függvényében, oszlopdiagram (amely- 
nél az oszlopok színe adja meg a hoz- 
zájuk tartozó jellemző állapotát — nor- 
mál, figyelmeztetés, vészhelyzet), valódi 
műszerek kijelzőjét utánzó rajzok. 
Ütemezési elvárásaink viszonylag eny- 
hék, nem váruk szigorúan valós idejű 
működést. Számunkra a programok által 
megvalósított valós idejű működés is 
megfelelő, tehát gépeinken normál 
Linux-rendszermag fut. Az adatgyűjtő, 
kiértékelő és adatcseremodulok kizáró- 
lag C nyelven íródtak, és egyazon szá- 
mítógépen futnak. A biztonsági, a nap- 
lózó és a megjelenítő modulok néme- 
lyike szintén ezen a számítógépen fut. 

A megjelenítő modulok egy része egy 
másik számítógépre került, amely az 
előbbi X termináljaként üzemel. Mind- 
két számítógép és a hozzájuk tartozó két 
monitor a próbapad vezérlőhelyiségé- 
ben található, így a működtető személy- 
zet minden adathoz hozzá tud jutni. 
Egyes megjelenítő modulok a kutatók 
gépein futnak, ezek az adatcseremo- 
dulon keresztül kapják az adatokat. 

A megjelenítő modulok viszonylag hosz- 
szabb idő alatt tisztultak le. Eleinte 
ncurses alapú, a szöveges linuxos 
konzolon dolgozó programjaink voltak. 
Később az X is képbe került, eleinte szab- 
ványos XI11 és Xt könyvtárakkal. A kö- 
vetkező lépés a SuSE-ből vett Motif 
kipróbálása volt. A nyílt forrású GIK egy 
vagy két évvel később jelent meg, és én 
azonnal áttértem rá. Az utóbbi két évben 
szinte az összes megjelenítő és egyéb 
modul TcI/Ik alapú, illetve erőteljesen 
támaszkodnak a BLI kiterjesztésre. 


Összegzés 

Éles ipari környezetben történő sok év 
programfejlesztés és -használat alapján 
arra a következtetésre jutottunk, hogy 
minden szempontból a nyílt forrású 
megoldások a leghatékonyabbak. A 
következő lépésünk az lesz, hogy a 
megmaradt kereskedelmi programokat 
is nyílt forrásúakra cseréljük le. 
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A vörösszemhatás eltávolítása GIIMP-pel 


Belefáradtunk azokba a fényképekbe, amelyekről a családtagjaink és barátaink 


"sátáni" szemekkel néznek vissza ránk? 


hogy napjainkban egyre inkább elárasztják a piacot az 
AA olcsó digitális fényképezőgépek és lapolvasók, úgy 

választja egyre több Linux-felhasználó a népszerű 
nyílt forráskódú GNU Image Manipulation Programot (GNU 
képszerkesztő program, rövidebb nevén: The Gimp), amikor 
digitális képeiket kívánják szerkeszteni. Írásunkban egy egy- 
szerű eljárást ismertetünk arra vonatkozóan, hogy pillanat- 
felvételeinkről miként távolíthatjuk el a Gimp segítségével a 
rettegett , vörös szemeket" . 
Az általam ismertetésre kerülő eljárással megmenthető a 
pupilla létfontosságú tonalitása, vagyis a különböző részein 
megjelenő sötét és világos árnyalatok változatossága. Ugyanígy 
változatlanul hagyja a pupillát fedő szaruhártyáról visszatükrö- 
ződő fényeket, amelyek a fényképezett személy életteliségének 
érzetét keltik. 
A Gimp legtöbb menüpontja a kép ablakán történő jobb 
egérkattintással hívható elő. Leírásomban a jobb egérkattintást 
JK-val fogom rövidíteni. Ha egy alkalmazandó Gimp-tevékeny- 
séget szeretnék leírni, zárójelek közé tett menüpontsorozatot 
vagy billentyűkombinációkat olvashatunk majd. Például egy 
kép megnyitásakor a (]JK- Filez Open) formát használom. Ha 
célszerűbbnek tűnik a billentyűkombinációs megoldás, listát 
közlök azokról a gombokról, amiket meg kell nyomnunk 
— például ilyen a kép másolására szolgáló CTRL-C. 
Következzen az eljárás. Indítsuk el a Gimpet, majd nyissuk 
meg a vörösszem-hatásban szenvedő képet (JK: FILEs OPEN), 
ahogy az 1. képen látható. Ha betöltöttük a képet, nagyítsuk ki a 
szem részletét (néhányszor megnyomva a 7 billentyűt 
és szükség esetén görgetve a képet), így a vörös pupillák egy 
szép nagy nézetéhez juthatunk. 
Következő lépésként a fotóalany pupilláját alkotó képpontokat 
szeretnénk kijelölni. Számos megoldás létezik erre, tapasztala- 
tom alapján a legjobban ezek közül a fuzzy select (képlékeny 
kiválasztás, másik elterjedt nevén ,magic wand" -— varázspálca) 
eszköz használható. Az eszköz a hasonló színárnyalatú pontok 
tartományának elvén működik. Ezen olyan területet értünk, 
amelynek pontjai a pillanatnyi ponthoz viszonyítva csak meg- 
határozott színeltérést mutathatnak (itt jelentkezik a , fuzzy" 
- képlékeny körvonalú - tulajdonság: beállíthatjuk ennek az 
eltérésnek a küszöbértékét). Minden RGB rendszerben tárolt 
kép (ez a legtöbb képformátum normál tárolási rendszere) 
három színcsatornából áll: vörös, zöld és kék (red, green, blue), 
amelyek minden képpont esetén meghatározott értéket vesz- 
nek fel. Ha ezeket a csatornákat egyenként megvizsgáljuk, 
rendszerint azt vesszük észre, hogy a pupillák fuzzy selecttel 
való kiválasztásához a zöld csatorna rendelkezik a legnagyobb 
kontraszttal. 
Hívjuk elő a rétegek (Layers) párbeszédablakát (CTRL-L), és 
kattintsunk a Channels (csatornák) fülre. Töröljük a kék (Blue) 
és vörös (Red) csatornák kiválasztását. A Layers párbeszédab- 
laknak a 2. képén látható képet kell mutatnia, csak a Green 
(zöld) csatorna legyen kiemelve. A két csatorna láthatóságát 
nem kapcsoltuk ki, így a kép ablakában nem észlelhető semmi 
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1. kép Aranyos kisgyerek vagy ördögfióka? 


változás, de azzal, hogy csak a zöld csatornát választottuk ki, a 
fuzzy select eljárás a szomszédos képpontok kiválasztásakor 
csak a zöld csatorna értékét veszi figyelembe. 

Most az eszköz beállítási lehetőségeinek megjelenítése céljából 
kattintsunk kétszer a fuzzy select (magic wand) eszközre a 
Gimp eszköztárában. A megfelelő küszöbérték (Ihreshold) 
beállításához egy kis gyakorlatra van szükség, de általában az 
alapértelmezett beállítás növelésére van szükség. Érdemes 
azzal az értékkel próbálkozni először, ami a 3. képen látható. 

A határvonal lágyságának (Feather) beállítását szintén érdemes 
megváltoztatni, valamilyen kis értéket adva neki, ahogy az 
ábrán látható. 

Most kattintsunk a képen a pupilla vörös tartományára. 
Látnunk kell a , menetelő hangyákat" a terület körül, ahogy 

a pupilla nagy részének kijelölése megtörténik. Ha nem megfe- 
lelő, töröljük a kijelölést (SHIFT-CTRL-A), finoman növeljük a 
küszöbértéket (Ihreshold), és próbálkozzunk újra. Ugyanígy 
ha a pupillán kívüli részek is kijelölésre kerültek, a küszöbérték 
csökkentésével próbálkozhatunk. lovábbi lehetőség a Grow 
selection (növekvő kiválasztás, JK: Selects Grow) és a Shrink 
selection (csökkenő kiválasztás, JK: SelectzShrink) párbeszéd- 
ablak — ha nagyjából jó az eredmény, csak néhány pont nem 
találta meg a helyét a kijelölés során. Ha megtörtént a pupilla 
megfelelő pontjainak kiválasztása, tartsuk lenyomva a SHIFT 
billentyűt és kattintsunk a másik pupilla vörös részére (a SHIFT 
nyomva tartása mellett történő kiválasztás a tartományt hoz- 
záadja a már kijelölt részhez). Most már mind a két pupillának 
az 4. képen látható módon kijelölt állapotban kell lennie. 

Egy tipp a Gimp gyakorlottabb felhasználói számára: ha ismer- 
jük a guick mask (gyorsmaszk) eszközt, ezzel is javíthatjuk a 
hibás kiválasztást. Kattintsunk a guick mask feliratú gombra, 


egy kisméretű lágy ecsettel 
végezzük el a megfelelő 


kijelölésre. 

Most térjünk vissza a rétegek 
(Layers) párbeszédablakra, jelöl- 
jük be a vörös (Red) csatornát és 
vegyük le a jelölést a zöldről 
(Green). Miután ellenőriztük, 
hogy csak a vörös van kivá- 
lasztva, színtelenítjük 
(desaturate) a kijelölt területet 
(K:Image: Colorsz 
Desaturate). 

Itt az idő, hogy szemügyre 
vegyük az eredményt. Kapcsol- 
juk ki a kijelölés láthatóságát 

ET anEladkkstn (CTRL-T), ezzel a pupilla körül 
——— — ] eltűnneka  masírozó hangyák" 
— jobban látszik, mit műveltünk. 
Azt nem árt tudatosítani, hogy 
a kijelölés még él, csak nincs 
látható jele. 

Ha elégedettek vagyunk az 
eredménnyel, kapcsoljuk vissza 
a kijelölés láthatóságát (CTRL-1), 
töröljük az összes kijelölést 
(CTRL-SHIFT-A), csökkentsük a 
nagyítást (-), hogy jobban szemügyre vehessük munkánk 
eredményét, és további változtatásokat hajtsunk végre. Ha 
nem tetszik az eredmény, kapcsoljuk vissza a kijelölés látható- 
ságát (CTRL-I) és a CTRL-Z billentyűkombinációval lépkedjünk 
vissza addig a pontig, ahonnan módosíthatjuk a kijelölést, 
vagy válasszunk más megközelítést a hiba kijavítására. 

Meg kell említenem ennek az eljárásnak egy olyan változatát, 
ami szerintem egy árnyalattal jobb eredményhez vezet. Ennek 
feltétele az, hogy Gimp példányunkra telepítve legyen a 
Channel Mixer (csatornakeverő) bővítmény. A Channel Mixer 
nagyszerű eszköz arra, hogy a kép részleteit vagy az egész 
képet fekete-fehérre változtassuk; jóval több beavatkozást 
enged a folyamatba, mintha csak egyszerűen a Desaturate 
szolgáltatást vagy az RGB- Grayscale átalakítást használjuk. 

A Channel Mixer nem része a Red Hat rendszerrel kapott 
GIMP 1.2.3 csomagomnak, de a Gimp-bővítmények nyilván- 
tartásában (Ihe Gimp Plugin Registry, registry.gimp.org) 
megtalálható. Egyszerűen fordítsuk le és másoljuk a saját 
könyvtárunkban lévő .gimp-1.2/plug-ins könyvtárba. 

Az eljárásnak ebben a változatában minden a fent említett 
módon Zajlik, de ahelyett, hogy a vörös csatornát színtelenítjük, 
minden csatornának töröljük a kiválasztását, és indítsuk el a 
Channel Mixert (IK: Filtersz Colors z Channel Mixer). Az eszköz 
lehetővé teszi, hogy az RGB értékeket tetszőleges százalékban 
keverjük. Jelöljük ki a Monochrome négyzetet, csökkentsük 
jelentős mértékben a vörös színt, és növeljük a zöldet. Én a 

6. képen látható arányokat használtam: 10990-nyi vörös, 60970-nyi 
zöld és 3090-nyi kék színt. Kell egy kis gyakorlat ahhoz, hogy 
kiválaszthassuk, melyik arány adja a pupillák leginkább valós- 
nak tűnő képét, de kiindulásként ez biztosan megfelel. 

Amikor az arányokat megfelelőnek találjuk, kattintsunk az OK-ra. 
Ha nem vagyunk biztosak benne, hogy az eredmény megfe- 
lelő, és más arányokkal szeretnénk próbálkozni, lépjünk vissza 
(CTRL-2), kapcsoljuk vissza a kijelölés láthatóságát (CTRL-1I), és 
futtassuk újra ugyanazt a szűrőt (SHIFT-ALT-F). A Channel Mixer 
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5. kép Az elkészült kép 


használatával elért eredmény a 7. képen látható: a pupillák szép 
sötétek, enyhe tónusbeli változás figyelhető meg a határvonal 
mentén, kellemes megjelenésű fényvisszaverődés látható a 
szemben. Ha az eredménnyel elégedettek vagyunk, akkor 
ahogy korábban is tettük, kapcsoljuk vissza a kijelölés látható- 
ságát (CTRL-1), töröljük az összes kijelölést (CTRL-SHIFT-A), és 
csökkentsük a nagyítást (-), hogy eredeti méretben vizsgálhas- 
suk meg munkánk eredményét. A 5. kép a Channel Mixer 
használatával elért végeredményt mutatja. 

Talán most egy kicsit bonyolultnak tűnik a módszer, de ha 
ráérzünk az ízére, néhány percnél nem vesz több időt igénybe. 
A legjobb az egészben, hogy az eredmény kitűnő minőségű, 
amit különösen nagyfelbontású tintasugaras nyomtatóval 
készített papírkép esetén tapasztalhatunk. 
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Útmutató GPRS-Biluetooth használatához 


Internetezés Bluetooth-kapcsolaton keresztül Linux alatt. 


Linuxvilág 21. számában már szóltunk a Linux alatti 
AA GPRS csomagkapcsolt adatátvitelről ( GPRS Linux 

alól is" címmel, 70. oldal). Részletesen tárgyaltuk, 
miképpen használjuk a soros kapura kötött telefont interne- 
tezésre. De arról nem esett szó, mi történjen akkor, ha új típusú 
alaplapot vettünk vagy laptopot használunk, és nincs rajta 
soros kapu. Előfordulhat az is, hogy kényelmi okokból nem 
ragaszkodunk a kábelrengeteghez, esetleg belefáradtunk abba, 
hogy nagyjából ötóránként lemerül a telefonunk. Támogatja 
készülékünk a Bluetooth-ot? Szerezzünk be egy USB-s 
Bluetooth-adaptert és máris használhatjuk kedvenc operációs 
rendszerünk alatt! 
Írásomban részletesen ismertetem, hogyan sikerült Debian 
Woody 3.0 és SuSE 8.1-es alatt egy Widcomm v.1.1 ESB-s Blue- 
tooth-adapterrel, Nokia 6310-es telefonnal, valamint Vodafone 
kártyával kiválóan működő GPRS-kapcsolatot megvalósítani. 
Célkitűzésünk eléréséhez elsőként egy 2.4.x-es rendszermag 
beszerzése szükséges. A telepítéshez kövessük az alábbi 
lépéseket! 


1. lépés — a rendszermagfordítás 
A következőket adjuk hozzá a /etc/modules.conf-hoz: 


HBluetooth kapcsolat 

options ppp async flag time-0 
H Bluez 

alias net-pf-31 bluez 

alias bt-proto-0O 12cap 

alias bt-proto-2 sco 

alias bt-proto-3 rfcomm 
alias bt-proto-4 bnep 


HBluez - UARTS 
aliás tty-1ldisc-15 hci uart 


2. lépés — a DNS beállítása 

A DNS-kiszolgálók beállítása következik — amennyiben ez már 
megtörtént, ugorjunk tovább. A beállításhoz a usepeerdns-t 
használjuk (sajnos némelyik telefon nem támogatja). Amennyi- 
ben nem működne, akkor kézzel kell beállítani a /etc/resolv.conf- 
ban. Valami ilyesmit kell a szövegszerkesztőben látnunk: 


nameserveri XXX.XXX.XXX.XXX 
nameserveri XXX.XXX.XXX.XXX 


lermészetesen az x-ek helyére egy valódi DNS-kiszolgáló IP-cíi- 
mét kell begépelni. Ezután ellenőrizni kell, hogy a /etc/host.conf 
tartalmazza-e az order hosts, bind sort. Miután mindezt 
végrehajtottuk, egy gyors rendszermagfordításra lesz szüksé- 
günk. A Bluetooth-támogatást tegyük modulba. 


t grep -i blue /usr/src/linux-2.4.19/.config 
CONFIG USB BLUETOOTH-m H?H Ezt a modult le kell 
majd t r lni! 


Linuxvilág 


Ezt a modult azért kell törölni, hogy ne a bluetooth. o modult 
töltse be a rendszer hanema hci usb.o-t - bár lehet, hogy 
van szebb megoldás is, nekem ez tűnt a legegyszerűbbnek! 


H Bluetooth support 

CONFIG BLUEZ-m 

CONFIG BLUEZ L2CAP-m 

CONFIG BLUEZ SCO-m 

H Bluetooth device drivers 

CONFIG BLUEZ HCIUSB-m 

t CONFIG BLUEZ USB FW LOAD is not set 
H CONFIG BLUEZ USB ZERO PACKET is not set 
t CONFIG BLUEZ HCIUART is not set 

t CONFIG BLUEZ HCIDTLI1 is not set 

t CONFIG BLUEZ HCIVHCI is not set 


Megjegyezném, hogy a SuSE 8.1-es rendszermagját szükség- 
telen volt újrafordítani, elegendőnek bizonyult a már említett 
/1lib/modules/2.4.19/kernel/drivers/usb/ 
bluetooth. o modul törlése. 

Nagyon fontos még, hogy a /usr/src/linux hivatkozásnak a saját 
rendszermagforrásunkra kell mutatnia. Ekkor állunk készen arra, 
hogy telepítsük a Bluetooth-kapcsolathoz szükséges fájlokat. 
Ezek a 3 http:/bluez.sourceforge.net/download/download.html 
oldalon érhetők el, de a Linuxvilág 45. CD-mellékletének 
Magazinr/Bluetooth könyvtárában is megtaláljuk őket: 


bluez-kernel-2.3.tar.gz (A create dev parancsfájl csak a 
Bluez CVS-ben található meg.) 


bluez-1libs-2.2.tar.gz 
bluez-utils-2.1.tar.gz 
bluúesz-sdp-0.8.tar.gz 
bluez-pan-1.1-prel.tar.gz 
bluez-hcidump-1.3.tar.gz 
bluez-hciemu-1.0.tar.gz 
bluez-bluefw-O.7.tar.gz 


A fájlokat ebben a sorrendben csomagoljuk ki, és egyszerűen 
a . /configure majd make és végül make insta11 paran- 
csokkal fordítsuk le, azután telepítsük őket. Futtassuk le 

a create dev parancsfájlt, és a /lib/modules/2.4.19/-es könyv- 
tárban adjuk ki a depmod -a parancsot, és máris elkészültünk 
a telepítéssel. 


3. lépés — a Bluetooth-kapcsolat beállítása 

A telepítést követően állítsuk be a Bluetooth-kapcsolatot. 
Mivel már telepítettük a programokat, rendelkezésünkre 

áll heiconftig, heitool rfcomm és 

/etc/init . d/bluetooth programunk, tehát használjuk 

is őket! (Ha esetleg SuSE alatt a /etc/init . d/bluetooth 
parancsot nem leljük, a $ cp bluez-utils-2.1/scripts/ 
bluetooth.rc.rh /etc/init . d/bluetooth paranccsal 
másoljuk a helyére.) Adjuk ki a /etc/init . d/bluetooth 


start parancsot, mire a /var/log/messages-ben valami hasonlót 
kell látnunk: 


Jan 13 07:45:08 debian kernel: BlueZ Core ver 
2.2 Copyright 1€) 2000,2001 O0üalcomm Inc 

Jan 13 07:45:08 debian kernel: Written 
2000,2001 by Maxim Krasnyansky 

cmaxkOogual comm. com: 


Adjuk ki az 1smod parancsot, és azt látjuk, hogy az alábbi 
modulok töltődtek be: 


1l12cap 17408 1. 
(autoclean) 

bluez 35048 1 
(autoclean) [12cap] 


Ha mindez megvan, adjuk ki a modprobe 

hci usb;modprobe usb-uhci parancsot, és már állíthatjuk 
is be az adaptert a hciconf ig parancs segítségével. 

Ha ekkor az adapter a 00:00:00:00:00:00 címet írja ki, sajnos 
nem működik, ezért adjuk ki a hciconfig hci0 down és 
hciconfig hci0o up parancsokat. Ezután a rendszernek már 
látnia kell az adapterünket. Ezt követően kapcsoljuk be a 
telefonon a Bluetooth-hozzáférést, és próbáljuk meg pingelni: 


Ht hcitool ing 

TInguirin 
00:02:EE:42:34:2B 
soffset: 0x3465 


clock 
class: 0x502204 


H l2ping 00:02:EE:42:34:2B 

Pind: DO:02:BE:42:34:28B Írom 00:10:60:29:17:28 
(data size 20) 

0 bytes from 00:02:EE:42:34:2B id 200 

Stime 34.10ms 

0 bytes from 00:02:EE:42:34:2B id 201 

5Stime 26.16ms 

2 sent, 2 received, 08 loss 

4. lépés — a GPRS beállítása 

Elérkezett az ideje, hogy GPRS-hozzáférésünket is beállítsuk. 
Amennyiben a Bluez-csomagokat rendben lefordítottuk és 
telepítettük, a /etc könyvtárban egy bluetooth/ nevű könyvtárat 
kell látnunk. 


H ls -1 /etc/bluetooth/ 

total 20 

drWXIrI-XrI-x 2 root root 
054096 Oct 30 00:27 firmware 


StWeTt oz ése l root root 
1371 00€t 29 19:24 Hcid.cont 
SÉW es zseez l1 root root 
67 Oct 30 00:07 pin 

-TYW-rT--TrT-- l1 root root 
505329 Nov 5 17:44 rfcomm.conf 


Az rfcomm.conf-ban a telefon címét át kell írni, mely így fest: 


H Bluetooth address of the device 
device 11:22:33:44:55:66; 


ez most nálam így néz ki: 
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H Bluetooth address of the device 
device 00:02:EE:42:34:2B; 


5. lépés — a telefon beállítása 

A telefonbeállításnál engedélyeztem a láthatóságot, valamint 
biztonsági okokból a pinkód (személyi azonosító kód) hasz- 
nálatát is beállítottam. A /etc/bluetooth/pin fájl tartalmazza a 
pinkódot, ami alapbeállításként 1234. Itt most egy pillanatra 
álljunk is meg, mert a hcid.conf-ban található egy olyan lehe- 
tőség, ami pinkódválasztáshoz nélkülözhetetlen, és ennek 

a futtatásához a python-gtk csomag szükséges. 


H PIN helper 
pin helper /bin/bluepin; 


Úgy gondoltam, hogy ez nem okozhat gondot, mert mindkét 
fent említett terjesztés tartalmazza. Ám tévedtem, mert nekem 
ez a szolgáltatás nem működött. A telefon , Eszköz nem elér- 
hető" vagy ,Hibás kód" hibaüzenetet adott. Szerencsére 

ez a nehézség is legyőzhető, ehhez a kódot a következőképpen 
írjuk át: 


H PIN helper 
pin helper /bin/btpin; 


Továbbá a /bin könyvtárban hozzunk létre egy btpin nevű 
parancsfájlt a következő tartalommal: 


B1/bin/bash 
echo "PIN:1234" 


Ezután már csak futtathatóvá kellett tenni, és amikor a telefon 
kéri, megadni a kódot. (Iermészetesen bármilyen pinkódot 
választhatunk!) 


6. lépés — a telefon csatlakoztatása 
Elérkezett az ideje, hogy most már csatlakoztassuk a 
telefonunkat! 


t rfcomm bind /dev/rfcommO 00:02:EE:42:34:2B 


A folytatáshoz még szükségünk lesz a gprs, gpors-connect - 
chat, gprs-disconnect -chat parancsfájlokra. Ezeket 
másoljuk be a /etc/ppp/peers/ könyvtárba. A gprs fájlban a 
következő módosításokat kell végrehajtani: a /dev/ttySx 
bejegyzést /dev/rfcommoO-ra kell cserélni, a sebességet 
115200-ra, a forgalomvezérlést crtscts-re kell állítani. 

Most már semmi sem állíthat meg minket, irány az Internet! Nincs 
más dolgunk, mint megfelelő jogosultságok birtokában kiadni a 
t pppd call gprs parancsot egy konzolban, hogy a kimenetét 
is követni tudjuk (45. CD Magazin/Bluetooth/kimenet.txt). 
lermészetesen PC-nket a Bluetooth segítségével nemcsak a 
telefonnal tudjuk összekapcsolni, hanem egy másik PC-vel is, 
ha például helyi hálózatot szeretnénk létrehozni. Ennek 
bemutatása azonban már túlmutat e cikk keretein. 


ám  ! Steinhausz Gábor (steingofreemail.hu) 

27 éves, nős, végzős informatikushallgató, hobbija 
a hegymászás és természetesen a Linux mint az 
asztali PC-k operációs rendszere. 
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A proftpd beállítása 


Egy sokoldalú FTP-kiszolgáló Apache-szerű beállítóállománnyal. 


z FIP (File Iransfer Protocol) egy igen régóta méltán 
AA népszerű protokoll, amelyet elsősorban hatékony állo- 

mányátvitelre terveztek. Mind belső hálózaton, mind 
az Interneten rengeteg felhasználási területe létezik. 
Te is könnyedén felállíthatsz egy FIP-kiszolgálót, viszont 
biztonságos beállításához több kell egy deb-, vagy egy RPM- 
csomag telepítésénél. Az FIP igen összetett protokoll, ugyan- 
akkor a vonatkozó rfc elolvasásával közelebb kerülhetsz a 
megismeréséhez. Ajánlom az rfc959-t, amely Debian alatt a 
proftpd-doc csomag része, és /usr/share/doc/proftpd- 
doc/rfc/rfcOo959.txt.gz néven érhető el. Mint láthatod, a 
proftpad telepítését Debian Woody alatt mutatom be, 2.4.19-es 
rendszermaggal és a Netfilter használatával. A parancsok más 
terjesztésekben eltérhetnek ettől, de a telepítés menete nagy 
vonalakban ugyanaz. 


Active és passiíve mód 

A lustábbak kedvéért a fontosabb fogalmakat itt ismerte- 
tem, de ez nem jelenti azt, hogy felesleges lenne elolvasni 

a fellel-hető leírásokat. Ne felejtsd el, hogy a különböző 
fórumokon (levelezőlistákon, IRC-n stb.) nem szívesen 
foglalkoznak olyan kérdésekkel, amelyekre valahol már 
léteznek válaszok. 

Egy jellemző FIP-kapcsolat a következőképpen fest: az ügyfél 
csatlakozik a kiszolgáló egy megadott kapujára (alapesetben 
eza 21/tcp - ftp). Ha a hitelesítés sikeres volt, a kapcsolat 
további része az eggyel alacsonyabb számú kapun folytatódik 
(20/tep - Ítp-data). Ezt követően kétféleképpen történhet 
a fájlátvitel. Active módban a kiszolgáló csatlakozik az ügyfél 
egyik kapujára, míg passive módban az ügyfél kapcsolódik a 
kiszolgálóhoz. A passive mód az alapértelmezett - ez a tűzfala- 
zásnál nyerhet nagy jelentőséget. A témától elszakadva: egy 
szigorú tűzfal esetén jó ötlet lehet a belső hálóról active mód- 
ban elérni egy FIP-kiszolgálót az Interneten, ha passive 
módban nem sikerül állományokat letölteni. Láthatod, hogy 
az active, illetve passive mód a kiszolgáló oldaláról nézve 
működő vagy tétlen. 


A proftpd telepítése 

A Debian Woodyban található proftpd csomag egy megbíz- 
ható változatot tartalmaz (1.2.5), így szerény véleményem 
szerint a kiszolgálót felesleges forrásból telepíteni. Ha valaki- 
nek mégis ez a rigolyája, az 1.2.7 változatszámút az 

2 ftp:/ftp.proftpd.org/distrib/source/proftpd-1.2.7.tar.bz2 
címről töltheti le, illetve a 45. CD Magazin/Proftpd könyv- 
tárában található. A deb-csomagot dselect-tel vagy egy 
hasonló apt-előtéttel célszerű telepíteni. A forrás lefordítása 
nem különösebben nehéz feladat: 


ny proftpd-1.2.7.tar.bz2z2 /üsrjsrő 

cd /uüúsrY/srce 

bzcat proftpd-1.2.7.tar.bz2 ] tar xv 
cd proftpd-1.2.7 

t ./configure --prefix-/usr 


H H 3 d 
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H make 
t make install 


A deb-csomag telepítése során a debconf felteszi azt a kérdést, 
hogyaz FIP-kiszolgálót standalone (önálló) vagy inetd 
módban szeretnéd-e futtatni. Önálló módban az ftp démon 
folyamatosan fut, és foglalja a számára kijelölt kaput, várva az 
ügyfelekre. Az inetd esetén az Internet Superserver fogja a 
kaput, és csak szükség esetén, azaz egy új ügyfél érkezésekor 
indítja el a démont. Az inetd-s megoldás kevesebb erőforrást 
emészt fel, ugyanakkor minden új ügyfelet megvárakoztatsz, 
hiszen türelmesnek kell lenniük, mire a démonfolyamat elin- 
dul. Általánosságban elmondható, hogy húsz felhasználó után 
már mindenképp érdemes önálló ftp démont futtatni. Ez 

a választás természetesen nem végleges, utólag könnyedén 
megváltoztathatod a döntésedet. 

Debconf esetén további kérdést jelent, hogy szeretnéd-e 
engedélyezni az úgynevezett anonim elérést. Ez azt jelenti, 
hogy regisztrált felhasználónév, illetve jelszó nélkül is el 
lehessen-e elérni a kiszolgálót, vagy sem. Anonim eléréskor 
az ügyfél felhasználónévként anonimoust (névtelen) ad meg, 
jelszóként pedig többnyire egy elektronikus levélcímet. Érde- 
mes nemmel válaszolni, s ezáltal kitiltani a vendégfelhaszná- 
lókat. A döntés nem végleges, hiszen utólag könnyű őket 
engedélyezni, de legalább a kiszolgáló beállítása alatt nem 
érhető el jelszó nélkül a rendszer. 


A fetc/proftpd.conf állomány 

Mint említettem, a proftpd beállítóállománya az Apache 

httpd.conf mintáit követi. Ennek megfelelően álljon itt egy lista 

a fontosabb irányelvekről: 

e ServerName ístring) 
A kiszolgáló nevét határozza meg. A kapcsolódást követően 
alapértelmezésben ezt a szövegfüzért látják a parancssori 
ftp-t használók: 
"PrOPTED 1.2.5$£0L S8ÉVSEÉ 
s [antes neti" 
Itt a Debian a ServerName által meghatározott név, míg 
az inter .net a számítógép úgynevezett FODN-je (Fully 
Oualified Domain Name), vagyis a tartománynév. 

e  ServerType ("inetd" ] "standalone") 
Itt a kiszolgálófolyamat futtatásának módját határozod 
meg. Az ineta, illetve standalone közötti különbség 
leírását lásd fentebb. 

e User (string) 
Annak a felhasználónak a neve, aki a démon tulajdonosa. 
Debian alatt alapértelmezésben ez nobody, viszont ezt a 
felhasználót más folyamatok is használják, így érdemes 
egy külön ftpd nevű felhasználót létrehozni /bin/false 
héjjal, és azt adni meg itt. 

e Group (string) 
Annak a csoportnak a neve, aki a démon tulajdonosa. 
Szintén ajánlott a nogroup helyett egy ftpd nevű felhasználó 
létrehozása. 


(Debian) 


e  DefaultRoot (string) Istring] 
Ez a parancs az angol szakszókincs szerint egy jail root-ot 
hoz létre, ami valójában egy ketrec a felhasználóidnak. 
Az első értékként megadott könyvtárból nem tudnak 
feljebb lépni, vagyis számukra ez az új gyökér. A könyvtár- 
név az egyes felhasználókra nézve lehet relatív. A második 
érték nem kötelező, ezzel egy vagy több csoportra engedé- 
lyezheted avagy tilthatod ezt a megszorítást. Például: 
"DefaultRoot - download, !upload" 
Ennek a segítségével eléred, hogy minden felhasználó, 
aki tagja a download csoportnak, de nem tagja az upload 
csoportnak, be legyen szorítva a saját könyvtárába (—). 

e  AllowForeignAddress íf"on" ] "orf") 
Engedélyezi az ügyfélnek, hogy a PORT ftp parancs 
használatakor a sajátján kívül más címét is használhassa. 
Ha nem érted, hogy ez mit jelent, akkor nem olvastad el az 
rfc-t, erre viszont most nem térnék ki. A lényeg, hogy ha 
ezt bekapcsolod (alapértelmezésben tiltva van), akkor a 
felhasználók igénybe vehetik az FXP nyújtotta lehetősége- 
ket. Az FXP egy olyan módszer (nem külön protokoll), 
amellyel két kiszolgáló között anélkül mozgathatsz állo- 
mányokat, hogy a saját gépedre letöltenéd őket. 

e  AuthUserFile ístring) 
Lehetőség van a proftpd-ben más forrásokból is meríteni 
a felhasználói adatbázist, nem kötelező a /etc/passwd-t hasz- 
nálni. Ez azért remek, mert az FIP-felhasználóknak nem 
kell feltétlenül létezniük a rendszerben. E források között 
szerepel az LDAP-, az SOL-kiszolgálók, illetve egy másik 
passwd állomány. Ezt az utóbbi forrást használja ez az 
irányelv, ami már elég nagyfokú biztonságot tesz lehetővé. 
Gondolj csak arra, hogy így könnyen megakadályozhatod 
az FIP-felhasználók távoli belépését telnet-en vagy ssh-n 
keresztül. Mivel azonban itt nem létezik az árnyékjelszó 
fogalma, óvatosan állítsd be a jogosultságokat arra az állo- 
mányra, amit itt értékként megadsz. A legjobb, ha a tulaj- 
donosa és a csoportja az, amit a User, illetve a Group meg- 
határozásnál megadtál, és csak a tulajdonos és a csoport 
tudja írni és olvasni, a többieknek pedig semmilyen jogo- 
sultságuk nincs. Az állományt az Étpasswd parancs segít- 
ségével lehet létrehozni, illetve karbantartani, közvetlen 
írása nem ajánlott. 

e AuthGroupFile (string) 
A hasonló nevű AuthUserFile-hoz hasonló, csak ez a 
/etc/group állományt helyettesíti. Szintén az Étpasswd 
paranccsal illik írni. 


Az ftnasswd 

Ez egy olyan könnyen használható segédeszköz, mely az 
AuthUserFile vagy az AuthGroupFile által megadott 
állományt módosítja. Kapcsolóit két egyszerű példán keresztül 
mutatom be. Létrehozok egy andras nevű felhasználót, és a 
download nevű csoportba teszem bele. 


H ftpasswd --passwd --name andras --uid 1000 
5.-gid 100 --home /home/andras --shell /bin/sh 


A - -passwd határozza meg, hogy a felhasználók adatbázisát 
szeretném módosítani, nem pedig a csoportokét. Lehetőség 
nyílik egy --file kapcsoló használatára, így meg lehet hatá- 
rozni az adatbázis nevét. Ha elhagyod, alapértelmezés szerint 
./ftpd.passwd, azaz a pillanatnyi könyvtárban egy ftpd.passwd 
nevű állomány. A többi kapcsoló magától értetődő. A - -gid-et 
elhagyhatod, ekkor egy a uid-del megegyező csoportazono- 
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sítót vesz alapul. Senkit ne tévesszen meg, hogy létezik egy 

- -shel1 kapcsoló, és egy valós héj van megadva utána! 

Ez nem jelenti azt, hogy az adott felhasználó be tudna lépni 
távolról telnet-en vagy ssh-n, hiszen nem is létezik a rend- 
szerben. Mindössze a PAM (Pluggable Authentication Modules) 
miatt van itt szükség egy valós héj megadására. Többek közt 
így lehet egy FIP-felhasználót , hibernálni": /bin/false-t 
adsz meg héjnak, legyen szó akár AuthUserFile-ról, akár 
nem. A felhasználó jelszavát ezután kétszer egymás után kell 
begépelned, akárcsak a passwd parancsnál. Ez a jelszó az 
adatbázisban titkosítva tárolódik. 


H ftpasswd --group --name download --gid 100 


A - -group azt mondja meg, hogy a csoportok adatbázisát 
módosítom. A --file elhagyása miatt az állomány neve 
./ftpd.group. Paranoiások figyelmébe ajánlom a --enable- 
group-passwd kapcsolót, ami szerintem ebben az esetben 
teljesen felesleges. 


A Netfilter beállítása 

FIP-kiszolgálót tűzfallal ellátni eléggé összetett feladat. 

A Netfilter ip conntrack ftp modulja ugyanakkor jelen- 
tősen leegyszerűsíti ezt a feladatot. Ez nyomon követi az 

ftp csomagokat, így azt sem szükséges tudnod, mi az az 
ftp-data kapu. Ha van ilyen modulod, egy szempillantás 
alatt beállítható (lásd a 45. CD Magazin/proftpd 
könyvtárában). 

Ha a tűzfaladnak nincs ftp-nyomkövető modulja, egy kicsit 
nehezebb lesz a dolgod. Először is engedélyezned kell az Étp 
(21), az ftp-data (20) kapukat, illetve a passzív átvitelhez 
mindazokat a kapukat, amik szóba jöhetnek. Ez érthető, hiszen 
az ügyfélnek el kell tudna érni azt a kaput, ahol az átvitel 
folyik. A gond csak az, hogy a kapu az 1024-65 535 tartomány 
bármelyik eleme lehet. Ha ezt mind engedélyezni akarod, ne 
is telepíts tűzfalat a kiszolgálóra. Azzal lehet segíteni az ügyön, 
hogy megmondod a proftpd-nek, hogy egy szűk tartomány- 
ból válasszon magának passzív kaput, és csak azt engedélye- 
zed a tűzfalban. Az utóbbi varázslat a PassivePorts megha- 
tározással hozható létre. 


PassivePorts (int) (int 

Az első egész szám az intervallum alsó, míg a második a felső 
határát jelöli (közöttük csak szóköz van). Fontos, hogy ez a 
tartomány elég nagy legyen ahhoz, hogy az elvárt számú 
kapcsolatot ki tudja elégíteni. Ennek megfelelően egy 

ip conntrack ftp-t nem használó IP lables tűzfalas FIP- 
kiszolgáló a 2. listán látható módon nézhet ki (lásd a 45. CD 
Magazir/proftpd könyvtárában). 


Végezetül 

A proftpd szolgáltatásait tekintve az egyik leggazdagabb FIP- 
kiszolgáló. A virtuális kiszolgálók létrehozásáról még szót sem 
ejtettünk. Sok szerencsét a kísérletezéshez, és írjatok bátran, ha 
valami kérdésetek van. 


Fülöp Balázs (xutofreemail.hu) 

18 éves, Imádja a Túró Rudlit, a Debian Linuxot és 
a teheneket. Az ELITE Radnóti Miklós Gyakorlóiskola 
tanulója Immár ötödik éve. Kedvenc Írója Slawomir 
Mrollek. Leginkább a számítógépes hálózatok 
biztonsága érdekli. 
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Mindaz, amit a memóriáról tudni érdemes 


Elérkeztünk következő nagy témakörünkhöz: a memóriakezeléshez. 


essünk egy pillantást az 1. ábrára, ami egy jellemző fo- 
lyamatrendszerű operációs rendszer felépítését mutatja. 
Eddig a két legalsó réteggel foglalkoztunk, a folyamat- 
és eszközkezelővel - ezeket az operációs rendszer magjának ne- 
vezzük. Ezen a szinten közvetlenül tarthatunk kapcsolatot a 
számítógép alkatrészeivel, és gyakorlatilag bármit megtehetünk. 
A továbbiakban az ábrán világoskékkel jelölt elemekről lesz 
szó, amelyet kiszolgálóknak (server) szokás nevezni, és a fel- 
használói alkalmazások számára kínálnak bizonyos szolgáltatá- 
sokat, olyanokat, amelyeket ők maguk képtelenek elvégezni. 

A kiszolgálók nem a rendszermag részei! Sokkal kevesebb jogo- 
sultsággal bírnak (például közvetlenül nem érhetik el a bevi- 
teli—kiviteli kapukat), mint például az eszközkezelők. A három 
legfontosabb kiszolgáló: a memóriakezelő, a fájlrendszer és a 
hálózatkiszolgáló. Az utóbbival nem foglalkozunk, mivel rész- 
letes ismertetése meghaladná e sorozat kereteit. A fájlrend- 
szerre azonban részletesen vissza fogunk térni, ugyanis ez 

lesz a következő, egyben utolsó nagy témakörünk. 
Mindenekelőtt azonban van még néhány fontosabb összefüg- 
gés a kiszolgálók és az operációs rendszer további részei között, 
amelyekre érdemes rávilágítanunk. Már sokszor kitértünk rá, 
hogy az operációs rendszerek két legfontosabb feladata az 
erőforrás-kezelés és a gép szolgáltatásainak kiterjesztése (az 
úgynevezett rendszerhívások bevezetésével). Láthattuk, hogy 
az erőforrások kezelésének oroszlánrészét a rendszermag 
végzi. Vajon mi foglalkozik a rendszerhívásokkal? A választ 
talán már sejtjük is: a kiszolgálók. Ők azok, akik értelmezik 

a beérkező rendszerhívásokat és az alsóbb rétegeket utasítják 

a kért feladat elvégzésére. 

Fontos még megemlítenünk, hogy a kiszolgálók maguk is fo- 
lyamatok, és alig különböznek valamiben a közönséges felhasz- 
nálói folyamatoktól. A két lényegbevágó különbség az, hogy 
egyrészt magasabb szinten futnak, tehát több mindenhez van 
jogosultságuk (már ha az adott gép processzora támogatja a 
védelmi szinteket, például ilyen a Pentium). Másrészt a kiszol- 
gálófolyamatok a rendszer indulásától kezdve egészen a leál- 
lításig folyamatosan futnak. 

Ennek a kiépítésnek az az előnye, hogy a kiszolgálókat akár 
egy másik, távoli gépen is futtathatjuk. Ennek köszönhetően 

— apró módosítások árán -— a fájlrendszert akár távoli fájlkiszol- 
gálóként is használhatjuk. 


Memóriarendszer 

Az operációs rendszerek esetében a memória pazarlása megen- 
gedhetetlen fényűzés. Főleg, ha figyelembe vesszük azt az örök 
igazságot (amelyet gyakran Parkinson törvényeként is emleget- 
nek), amely szerint a programok mindig kitöltik a rendelke- 
zésre álló memóriát. Könnyen elképzelhető, hogy nemsokára 

1 GB memória már egy kiló kenyér árával fog vetekedni, 
ugyanakkor abban is biztosak lehetünk, hogy a jövő alkalma- 
zásai már nem fogják annyival beérni, mint a maiak. 
Világunkra az is jellemző, hogy többféle memóriát forgalmaz- 
nak. Akad nagyon gyors, ám rendkívül kicsi, felejtő és drága. 
Ugyanakkor nagyon olcsó, rettentő nagy kapacitással bíró, 
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Rendszermag 


1. ábra A folyamatstrukturált operációs rendszer elvi felépítése 





tartalmát áramszünet esetén is megtartó, ellenben borzalmasan 
lassú is található közöttük. Az az egy azonban, amelyre min- 
denki áhítozik, a határtalan kapacitással és sebességgel bíró, 
mindenki számára megfizethető és tartalmát örök időkre 
megjegyző memória egyelőre sajnos még csak a vágyálmok 
birodalmában létezik. 

Ha létezne, bizonyára minden gépbe ezt szerelnék, és nem 
lenne ennyi gond a memóriakezeléssel. Mivel nem ez a hely- 
zet, a legtöbb számítógépben található memóriák a következő 
módon szerveződnek rendszerbe: legfelül a kicsi, ám rendkívül 
gyors és drága gyorstár (cache), alatta a már nem annyira 
gyors, de nagyobb kapacitású és olcsóbb központi memória 

(ez a RAM), végül a legalsó rétegben az akár több gigabájtos, 
olcsó, lassú, de nem felejtő lemezes tároló található. (A köz- 
ponti memóriát gyakran operatív tárnak is nevezik. Ez arra 
utal, hogy maga a futtatott program is itt foglal helyet.) 

A hierarchikus memória kezelése nem egyszerű feladat: nem- 
csak azt kell megszerveznünk, hogy a szabad memóriarészeket 
nyilvántartsuk, és hatékonyan osszuk ki őket a futó programok 
között, hanem figyelni kell arra is, hogy mit melyik memóriá- 
ban tárolunk. Ha egy folyamat például blokkolt állapotban van, 
akkor a központi tárból nyugodtan kitehetjük a lemezre, ezzel 
is felszabadítva némi helyet a többi program számára. 

Az operációs rendszernek azt a részét, ami ezeket a feladatokat 
megvalósítja, memóriakezelőnek nevezzük. 


Memóriakezelés lemez nélkül 

A legegyszerűbb memóriakezelők nem használják a lemezt, 
csak a központi memóriával gazdálkodnak. Ezek közül is a 
legalapvetőbb az, amikor a memóriában egyszerre csak egy 
programot tárolunk - ezt a taktikát alkalmazta az MS-DOS is. 
Az operációs rendszer a lemezről betölti a kívánt alkalmazást 
a központi tárba (tekintet nélkül arra, hogy mi volt benne 
előzőleg), majd végrehajtja. Amint a program lefutott, kezdőd- 
het minden elölről. Ennek a módszernek a megvalósítása 
rendkívül egyszerű, viszont nem teszi lehetővé több program 
egyidejűleg való futtatását, mivel az egész memóriát egyetlen 
programnak adományozta. 

Egy többfeladatos operációs rendszerben azonban a memóriát 


egynél több programmal is meg kell osztani. A már legendásnak 





számító 05/360-as rendszerben a következő módszert alkalmaz- 
ták: a memóriát több különböző méretű részekre, úgynevezett 
lemezrészekre osztották fel, amelyek méretét az operátornak 

a rendszer indulásakor előre meg kellett határoznia. Amikor 

a program elindult, a rendszer megkereste magának azt a leg- 
kisebb lemezrészt, amelyikbe a program még belefért. Miután 
megtalálta, berakta a lemezrész várakozási sorába, és várta, hogy 
felszabaduljon. Miután felszabadult, a program betöltődhetett 

a kiválasztott memória- 
részbe, és elkezdődhetett 
a végrehajtása. Ennek 

a módszernek MFI 
(Multiprogramming with 
Fix Iasks, lásd 2. ábrán- 
kon) volt a neve. 

Az MFI-vel rengeteg 
gond akadt. Pazarló 
módszernek bizonyult, 
hiszen előre megadott 
méretű lemezrészek 
voltak, így hiába hasz- 


Beérkezési 
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náltuk ki csak a felét 
a számunkra kiosztott 
memóriaszeletnek, 





akkor is elveszett az 
egész. Az operátornak 
ezért mindig mester- 
kednie kellett, hogy 
alkalmas méretű 
lemezrészeket hozzon létre, figyelembe véve olyan szempon- 
tokat is, hogy például az adott munkanapon inkább nagyobb 
vagy kisebb memóriaigényű programokat fognak-e futtatni. 

A másik baj az volt, hogy könnyen előfordulhatott olyan eset, 
amikor egy-egy kisebb lemezrészért több program is sorban 
állt, míg a nagyobbak senkinek sem kellettek. Ekkor egy olyan 
módosítást találtak ki, hogy csak egy várakozási sor legyen, és 
ha egy lemezrész kiürül, akkor a rendszer azt a programot tölti 
be a megüresedett helyre, amelyik a legjobban ki tudja hasz- 
nálni a lemezrészt és amelyik ezek közül legelöl áll a sorban. 
Ezzel a megoldással az volt a gond, hogy kirekesztő módon 
viselkedett a nagyon kicsi alkalmazásokkal szemben, mert ha 
kizárólag a méretüknél sokkal nagyobb lemezrészek ürültek ki, 
csak akkor töltődhettek be az üres helyre, ha nem várakozott 
másik, náluk nagyobb alkalmazás egy üres memóriaszeletre. 
Az MFT a legkönnyebben megvalósítható olyan memóriakezelő 
módszer, amelyik azt támogatja, hogy egyszerre több program is 
a memóriában legyen. Sok évig sikerrel alkalmazták a nagygépes 
rendszereken - fent említett hátrányai ellenére. Ma már azonban 
sehol sem alkalmazzák, és egyetlen rendszer sem támogatja. 


2. ábra 
Memóriakezelés az 05/360-asban 


Relokáció és védelem 

Még mielőtt belemerülnénk a ma használatos memóriakezelési 
eljárásokba, nem árt, ha előtte megemlítünk két olyan nem 
elhanyagolható nehézséget, amelyet minden memóriakezelési 
eljárásnak meg kell tudnia oldani. 

Amikor egy programot lefordítunk, az utolsó lépésben, amit 
összeépítésének vagy szerkesztésnek nevezünk, a főprogramot, 
az eljárásokat és az osztott könyvtárakat (erről bővebben a 
következő részben szólunk) egy közös címtérben helyezzük 

el. A szerkesztést végző alkalmazásnak (linkernek) tudnia kell, 
hogy a főprogram hol fog kezdődni, és merre helyezkednek el 
majd azok az eljárások, amelyek a végrehajtás során meg- 
hívásra kerülnek. 


www.linuxvilag.hu 


Nehézség abból adódik, hogy a betöltéskor minden program 
más címtartományba kerül, és sosem tudhatjuk előre, hogy a 
mi programunkat melyik memóriarész fogja megkapni. Amikor 
a program végrehajtása elkezdődik és egy olyan utasítást kap, 
hogy például hívjuk meg az 50-es címen lévő eljárást, gond 
van. Az 50-es cím az operációs rendszer területéhez tartozik 

— a program nyilvánvalóan nem arra a címre kíván ugrani, 
hanem a saját lemezrészének kezdetéhez viszonyított 50-es 
címre. A megoldás az lenne, hogy a lemezrész kezdeti címéhez 
hozzáadjuk a program által megadott címet, így megkapjuk 

a meghívandó eljárás valódi helyét. Ezt a műveletet nevezzük 
eltolásnak (relocation). 

Az operációs rendszerek különböző módon oldják meg a fenti 
feladatot, azaz a áthelyezést. Az előbb már említett 05/360-as 
például a program betöltésekor önműködően módosította az 
utasításokat, úgy, hogy minden címhez hozzáadta a kiválasz- 
tott lemezrész kezdőcímét. Ehhez azonban az kellett, hogy a 
szerkesztőprogram egy térképet helyezzen el, ami a rendszer- 
nek megadja, hogy mely értékeket kell úgymond , relokálni" . 
Ez a módszer még ma is használatos, főleg a mikroszámítógé- 
pek világában. 

Az áthelyezéssel szorosan összefügg a védelem kérdése. Az 
imént bemutatott módszerben a programok abszolút címekkel 
dolgoznak, ezáltal némi ügyeskedés segítségével könnyen írha- 
tunk olyan programot, amelyik képes belepiszkálni más folya- 
fenntartott területre is. 

A védelem megvalósításának módja szorosan összefügg az 
áthelyezéseknél alkalmazott módszerrel, sőt az is fontos, hogy 
az adott rendszer milyen gépen fut. A legtöbb eszköz ugyanis 
segít e két dolog megvalósításában az operációs rendszernek. 
Maradjunk a szokásos példánál az 0S/360-assal. Itt a memóriát 
2 KB-os blokkokra osztották, és minden blokkhoz hozzáren- 
deltek egy négybites kulcsot, amelyeket csak az operációs 
rendszernek áll módjában megváltoztatni. Amikor egy prog- 
ram hozzá akart férni egy memóriablokkhoz, a programál- 
lapotszó-regiszterbe (PSW) be kellett tölteni az adott blokkhoz 
tartozó kulcsot. Az ellenőrzés eszközszinten történt, és ha a 
kód nem egyezett, a művelet nem hajtódott végre. 

Sokkal elterjedtebb volt egy másik módszer, amelyik egyszerre 
kínált megoldást az áthelyezésés a védelem kérdésére. Az esz- 
köz két egyedi regiszterrel rendelkezett: a bázis- és a háttér- 
regiszterrel. Amikor egy folyamat megkapta a futási lehetősé- 
get, a bázisregiszterbe betöltődött a program memóriarészének 
kezdőcíme, a háttérregiszterbe pedig annak mérete. Innentől 
kezdve az eszköz minden memóriacímet a bázisregiszterhez 
viszonyított, így az operációs rendszernek többé nem kellett 

a kód módosításával foglalkoznia. A háttérregiszter jelenléte a 
védelem kérdését is megoldotta, mivel ha a program egy olyan 
címre akart hivatkozni, amelyik saját memóriarészén kívül volt 
(azaz a háttérregiszternél egy nagyobb értékre hivatkozott), 

a rendszer azonnal gyilkolt. 

Ezt a módszert sok helyen alkalmazták, még az első IBM 
PC-kben található Intel 8088-as processzorok is ezen alapultak 
(habár itt mellőzték a háttérregisztert, így a védelmi részét 
gyakorlatilag kiiktatták). A 286-os processzoroktól kezdve 
azonban egy teljesen más módszer jelent meg, amit védett 
módnak (protected mode) nevezünk. De minderről majd a 
következő részben szólunk. 


Csereterület és virtuális memória 


Az emberiségnek hamar szembesülnie kellett azzal a ténnyel, 
hogy a memória sosem elég, és az összes futó program egy- 
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szerre általában nem fér el a memóriában. Ezért a központi 
tárat ki kell egészíteni a lemezzel. A lemezes tárolók a memó- 
riához képest ugyan lassúak, viszont sokkal nagyobb kapacitás- 
sal rendelkeznek, tehát nyugodt szívvel odapakolhatunk min- 
den olyan dolgot, amire az adott pillanatban nincsen szükség, 
például a blokkolt folyamatok memóriarészeit. 

A lemez és az operatív tár közötti ide-odapakolás megvalósítá- 
sára kétféle megközelítés is létezik. Az első módszer a csere. 
Ilyenkor a programokat csak teljes egészükben mozgathatjuk 
a lemez és a központi memória között. 

A csere azonban nem jelent megoldást arra a helyzetre, ha 

a futtatni kívánt program meghaladja a rendelkezésre álló 
szabad memória méretét. Ilyenkor hajdanán az volt a bevett 
szokás, hogy a programokat rétegekre darabolták, és ezeket 

a rétegeket megszámozták. Először a 0. réteg töltődött be a 
memóriába és kezdett el futni. Amikor a végrehajtás befejező- 
dött, betöltötték a következő részt, és folytatódott tovább a 
program végrehajtása. Ezt overlay módszernek nevezik. Csak 
egy gond volt vele: programjának részekre való bontását a 
programozónak saját magának kellett megoldania. (Szeren- 
csére a rétegek cseréjét az operációs rendszer maga is el tudta 
végezni). Ez nem volt igazán szórakoztató elfoglaltság, ezért 
egyre inkább felmerült az igény egy olyasfajta megoldás meg- 
alkotására, amely a programozót megkíméli az effajta lélekölő 
tevékenységektől. 

Ekkor jött a nagy ötlet: a virtuális memória. Lényege az, hogy 
a programnak mindig csak azok a részei tartózkodnak a memó- 
riában, amelyekre éppen szükség van - a többit a lemezen tá- 
roljuk. A virtuális memória másik vonzó tulajdonsága, hogy 
több program együttes futtatásánál is alkalmazhatjuk. Ebben 
az esetben több program darabjai tartózkodnak a memóriában. 
Háromféle megvalósítását ismerjük a virtuális memóriának: 

a lapozást, a szegmentálást és a két módszer egyszerre való 
alkalmazását. 


A lapozás 

A virtuális memóriának az a kiinduló gondolata, hogy ketté- 
választjuk a címtartomány és a memóriarekesz fogalmát. Hogy 
ez mit is jelent? Vegyünk példának egy olyan számítógépet, 
amely mondjuk 4 KB (4096 bájt) fizikai memóriával rendelkezik. 
A gép regiszterei 16 bitesek, így pontosan 65 536 bájt megcímzé- 
sére nyílik lehetőségünk. Az, hogy egy számítógép mekkora 
memóriát tud kezelni, kizárólag címregiszterei hosszától függ. 
Azoknak az értékeknek a halmazát, amelyet a címregiszterek 
felvehetnek, a számítógép címtartományának nevezzük. Jelen 
esetben ez a 0, I, ... , 65 535. Ez azt jelenti, hogy legfeljebb 64 KB 
memóriát tudunk címezni (tehát hiába van a gépben mondjuk 
128 KB memória, akkor is csak 64-et lehet belőle használni). 
Amikor nem létezett még a virtuális memória, a memóriacíme- 
ket két részre osztották: a hasznosakra és a haszontalanokra. 
Az utóbbi csoportba nyilván azok a címek sorolódtak, amelyek- 
hez már nem tartozott valódi memóriarekesz, azaz jelen pél- 
dánknál maradva nagyobbak voltak, mint 4095. 

Itt az ideje kettéválasztani a címtartomány és a memóriarekesz 
fogalmát. Számítógépünk egyszerre csak 4096 bájtot tud a me- 
ne feltétlenül a 0 és 4095 közé essenek. Mondhatjuk azt is, 
hogy a fizikai memória első rekeszéhez rendelt cím legyen 
inkább a 4096, a második rekeszéhez a 4097, és így tovább. Ha 
úgy tetszik, egy leképezést (függvényt) határoztunk a címtarto- 
mányból (0 ... 65 535) a valódi memóriacímekre (0 ... 4095). 

Mi ebben a tudomány? Ha a gépben nincs virtuális memória, 
akkor úgymond állandó leképezésünk van a 0 és 4095 közötti 
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címekre. Ha valamelyik program e tartományon kívül címezne, 
bizony csúnya véget ér a történet (például egy hibaüzenet 
kíséretében megszakad a futása). Ha viszont a virtuális memória 
működik, és tegyük fel, a 8192 és 12 287 közötti címet szeret- 
nénk elérni, akkor a következő történik: először is mindaz kiíró- 
dik a lemezre, ami eddig a memóriában volt. Ezután meg kell 
keresni a 8192 és 12 287 közötti tartományt a lemezen, majd be 
kell tölteni a memóriába. Legvégül egy új leképezést kell létre- 
hozni a virtuális és a fizikai memóriacímek között (3. ábra). 


Virtuális memória 


Virtuális címtartomány Fizikai címtartomány 
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3. ábra A virtuális és a fizikai címtartomány kapcsolata 


Ezt az eljárást lapozásnak nevezzük, a lemezről beolvasott 
memóriadarabkákat pedig lapoknak. A fent említett leképezés 
a virtuális és a fizikai címek között tulajdonképpen egy táblá- 
zat, amelyet laptáblának vagy memóriatérképnek hívunk. 

(A fenti példában feltételeztük, hogy van elegendő hely a leme- 
zen ahhoz, hogy az egész címtartományt lefedhessük. A való 
életben ez nincs mindig így, de az elv akkor is ugyanaz marad). 
A virtuális és a fizikai címtartományt mindig azonos méretű 
blokkokra bontjuk (ezek lesznek a lapok), a méret mindig a 
kettő valamelyik hatványa. Manapság az általános lapméret 
512 bájt és 64 KB közé esik, de ez mindig az adott feladattól 
függ. Így nem ritka a több megabájtos lapméret sem. A fizikai 
címtartomány egy-egy blokkjába fogjuk betölteni a lapokat, és 
ezeket lapkereteknek nevezzük. 

Fel szeretnénk hívni a figyelmet arra, hogy sem a programozó, 
de még maga a futó program sem tud semmit minderről. 

A programozónak úgy kell megírnia a kódját, mintha nem is 
lenne lapozás. Ő a memóriát irtózatosan nagynak, folytonos- 
nak és lineárisnak látja. Például nem kell olyan dolgokkal fog- 
lalkoznia, hogy az adott memóriaszelet most a központi tárban 
vagy a lemezen van-e. A virtuális memória másik megvalósí- 
tása esetén a következő részben tárgyalt szegmentálásnál már 
egy kicsit más a helyzet, ott már nem árt, ha a programozó is 
tud a szegmensek létezéséről. 

Mielőtt egy példán részletesen bemutatnánk a lapozás műkö- 
dését, a könnyebb megértés végett sokat segítene, ha a lemezt 
úgy képzelnénk el, mint azt a dolgot, ami az adott program 
memóriában helyezkedik el, az annak a másolata. lermésze- 
tesen, ha a memóriában megváltozik a tartalom, a változásnak 
a lemezen is végbe kell mennie. 

Lássuk, miként fest ez a gyakorlatban! legyük fel, hogy van 

32 kilobájtos fizikai memóriánk és ehhez 64 kilobájt virtuális 
memória tartozik. A lapméret legyen 4 KB, ami azt jelenti, hogy 
a fizikai memóriában egyszerre nyolc lapot tárolhatunk (más- 
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5. ábra Az MMU címátalakításának folyamata. 
Jelen gép processzora 15 bites címekkel dolgozik, de a virtuális 
címtartomány mérete 16 bit. Az MMU feladata az, hogy a 16 bites 
virtuális címből 15 bites valódi címet készítsen 


ként fogalmazva: nyolc lapkeretet tartalmaz). Mivel a virtuális 
memória 64 kilobájtos, ezért ott kétszer annyi, azaz 16 lap 
raktározása lehetséges. Ne feledjük, hogy lemezeinken mindig 
az összes lap tárolódik, még azok is, amelyek éppen a memó- 
riába is be vannak töltve. lehát a példánkként szolgáló számí- 
tógép összes memóriája együttesen 64 KB és nem 32 - 64 KB! 
A 64 kilobájtos memóriánkat tehát felosztottuk egyenlő részek- 
re, jelen esetben 4 kilobájtos lapokra, így összesen 16 lappal 
gazdálkodhatunk. A fizikai memóriába ezek közül be van 
töltve valamelyik nyolc. Hogy melyik nyolc, azt a laptáblából 
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olvashatjuk ki. Ez tulajdonképpen egy táblázat, ami pontosan 
annyi bejegyzést tartalmaz, ahány lapunk van. Minden bejegy- 
zéshez egy úgynevezett jelenléti bit tartozik, ami azt mondja 
meg, hogy az adott lap éppen be van-e töltve a fizikai memó- 
riába vagy sem. Ha be van töltve, akkor azt is kiolvashatjuk 

a táblázatból, hogy melyik lapkeretében találhatjuk (4. ábra). 
Nézzük meg, mi történik, ha a program végre szeretne hajtani 
egy MOV REG, 20818 gépszintű utasítást (firmware). Ez az 
utasítás jelentse azt, hogy valamelyik regiszterbe be szeretnénk 
tenni az 5000-es címen található értéket (és tegyük fel, hogy a 
címregiszter 16 bit hosszúságú). lermészetesen ez egy virtuális 
cím, amivel a processzor nem igazán tud mit kezdeni, ezért 
majd át kell alakítani fizikai címmé. 

Erről az úgynevezett MMU (Memory Management Unit, azaz 
a memóriakezelő egység) gondoskodik. Ez egy olyan eszköz, 
ami általában a processzorlapkán foglal helyet, de van olyan 
változata is, amelyben külön van választva a processzortól. 
Akárhogy is, a feladata ugyanaz. 

Az MMU tehát megkapja az 20 818-os virtuális címet, és egyből 
egy 4 bites, úgynevezett virtuális lapszámra és egy 12 bites 
offsetre bontja. Az, hogy a címből hány bit a lapszám, és 
mennyi az offset, csakis attól függ, mekkora méretű lapokkal 
dolgozunk. (Mivel mi 4 KB-osakkal munkálkodtuk, ezért 12 bit 
az offset, mert 27 az pontosan 4096). Ezzel meg is állapítottuk, 
hogy az 5. virtuális lapon van a keresett adat (a számozást a 
nullával kezdjük). 

A következő feladat, hogy megkeressük a laptáblában az 5. 
laphoz tartozó bejegyzést, és megnézzük, hogy a memóriában 
található-e. Ha a jelenléti bit egyre van állítva, akkor igen, és 
kiolvassuk, hogy melyik lapkeretben lelhető fel — mondjuk az 
ötödikben. Ekkor már gyerekjáték megadni a fizikai címet, 
csupán ki kell számolnunk, hogy hol kezdődik az ötödik lap- 
keret, és hozzá kell adni az offsetet. Az így kapott értéket a 
processzor már fel tudja dolgozni. 

Igen ám, de mi történik, ha az adott lap mégsincs a fizikai 
memóriában (tehát a jelenléti bit nulla). Ebben az esetben 
laphibáról beszélünk. Ilyenkor az operációs rendszernek meg 
kell keresnie a merevlemezen a kért lapot, majd be kell töltenie 
valamelyik lapkeretbe. Ha ez megtörtént, az egész művelet 
kezdődhet elölről. 

Nem mindegy, hogy melyik lapkeretbe töltjük be az új lapot. 
Azt az elvet, ami alapján az operációs rendszer eldönti, hogy 
melyik lap helyére tegye be az újat, lapcserélési algoritmusnak 
nevezzük. 

Vegyük észre, hogy a feladat oroszlánrészét az eszközök végzik 
el, az operációs rendszernek csak akkor kell intézkednie, ha a 
kívánt lap nem tartózkodik a fizikai memóriában. A mai kor- 
szerű processzorok szinte kivétel nélkül támogatnak valamely 
virtuális memóriát kezelő módszert. Pentium processzorokban 
például ez a képesség nagyon fejlett, a lapozás mellett a szeg- 
mentálást és a kettő együttes kombinálást is támogatják. Az 
UltraSparc processzorok esetében is a virtuális memória lap- 
szervezésű. Mindezek ellenére egyre jobban kezd elterjedni a 
lapkezelés programon keresztüli megoldása. A mai RISC-pro- 
cesszorokat támogató gépek, például az Alpha esetében ez már 
így működik. Hogy miért ezt a módszert használják, arról a 
következő részben fogunk szólni. 
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Eszközválasztás 


Érvek és ellenérvek négy webfejlesztő eszköz — a mod perl/őMason, 
a J2EE, a Zope és az OpenACS - mellett és ellen. 


a valaki arra kérne bennünket, hogy nevezzük meg 
a a legjobb autót a piacon, valószínűleg azt válaszol- 

nánk, hogy ez attól függ, ki fogja használni azt az 
autót. Végül is egy manhattani nyolcfős család valószínűleg 
más típusú járművet szeretne, mint egy agglegény kódlovag 
Észak-Dakota faluvidékén. Ugyanez igaz a programozási 
nyelvek és a fejlesztőeszközök estében is. Mindegyiknek 
megvan a maga helye és alkalmazási területe. 
Bár ez nyilvánvalónak tűnhet, számos programozó úgy gondolja, 
hogy az általa használt eszközkészlet vagy nyelv bármikor bár- 
mely feladat megoldására alkalmas. Mint a régi mondás tartja: 
ha egyetlen munkaeszközöd egy kalapács, minden teendő olyan, 
mint egy szög. Egyetlen programozási nyelv sem tökéletes az 
összes feladathoz. Ezért ismernek a tapasztalt programozók több 
különféle nyelvet és tanulnak meg folyamatosan újakat. 
Egészen az utóbbi pár évig a programozók programjaikat több- 
nyire sebességre és alacsony memóriaigényre igazították. Ez ért- 
hető, hiszen a processzorok viszonylag lassúak, a memóriák pe- 
dig elég drágák voltak, így aztán amelyik program nem a legtöb- 
bet próbálta meg kipréselni az alkatrészekből, az vacaknak tűnt. 
Manapság azonban már az olcsóbb, gyors számítógépek és a 
kedvező árú, méretes memóriák áldásait élvezhetjük. Ez azt je- 
lenti, hogy a programtervezőknek lehetőségük nyílik olyan nyel- 
veket használni, amelyek a gyors fejlesztést és a hosszú távú 
programkarbantartást részesítik előnyben. Ez nem azt jelenti, 
hogy ellenzem a memória vagy sebesség javítását, egyszerűen 
csak kevésbé tartom fontosnak ahhoz képest, hogy üzembiztos, 
karbantartható programokat fejlesszünk gyorsan és egyszerűen. 
Közel két évvel ezelőtt elhatároztam, hogy egy hosszú cikkso- 
rozatot szentelek négy alapvető webfejlesztő módszernek: a 
mod perl/Mason (Linuxvilág 1., 3-4. szám), a JZEE (Linuxvilág 
13-14. szám), a Zope (Linuxvilág 15-19. szám) és az OpenACS 
rendszereknek (Linuxvilág 22-25. szám). Ezek a rendszerek 
nemcsak érdekesek és hasznosak, de egyben gondolatébresz- 
tők, továbbá új távlatokat nyitnak a webfejlesztők előtt. Bár az 
egyes közösségek között néha fellángolnak a viták arról, hogy 
melyik termék a legnagyszerűbb, a valóság az, hogy mindegyik 
egy kicsit más típusú feladatot próbál megoldani. 
E hónapban arra szánunk egy kis időt, hogy megpróbáljuk 
összefoglalni az elmúlt pár évben megismert keretrendszereket 
és ötleteket. lermészetesen nem várom azt, hogy aki a cikket 
elolvassa, azonnal az összes itt megnevezett alkalmazást hasz- 
nálja is; mindössze abban reménykedem, hogy a legelfogultabb 
rajongónak is egy kis gondolkodnivalót tudok nyújtani. 


mod perl/Mason 

Az Apache megérdemelten a nyílt forrású kezdeményezések 
egyik mintapéldánya. Megbízható, jól beállítható, kitűnően 
leírt, üzembiztos és bővíthető. Lenyűgöző dolgokat vihetünk 
végbe az Apache-csal, és sokféle módon igazíthatjuk hozzá 
saját igényeinkhez. Ha olyan webalkalmazást kell írnunk, 
aminek a lehető leggyorsabban le kell futnia, új modulokat 
írhatunk C-ben, amelyek aztán zökkenőmentesen 
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illeszkednek az Apache-hoz. 

Bár a C-programok gyorsan végrehaj- 
tódnak, és az Apache-könyvtárak 
(amelyeket manapság Apache Portable Runtime 
néven ismerhetünk) igencsak széles körű szolgáltatásokat és 
támogatást adnak a modulok alkotóinak, a fejlesztés C alatt 
lassabb és hibákra hajlamosabb, mintha valamilyen magasabb 
szintű nyelv, például Perl vagy Python alatt dolgoznánk. Így 
aztán talán nem is meglepő, hogy léteznek olyan Apache- 
modulok, amelyek ezeket a nyelveket ágyazzák be az Apache 
kiszolgálóba. A mod perl lehetővé teszi, hogy C helyett Perl 
nyelven készítsünk Apache-modulokat - a Perl sebességét és 
rugalmasságát meglovagolva —, miközben közel korlátlan 
uralmat kapunk kiszolgálónk felett. 

Tulajdonképpen ha valaki nagy teljesítményű webalkalmazást 
kér tőlem, különösen ha szövegfeldolgozás vagy relációsadat- 
bázis-kezelés is a feladat részét képezi, amod perl mindig 
előtérbe kerül. Megírhatnám a modult C-ben is, de minek baj- 
lódjak vele? Előfordul, hogy valóban érdemes C alatt dolgozni, 
de a legtöbb esetben a mod per1 sebességét még a nagy telje- 
sítményű alkalmazások esetében is kielégítőnek találtam. 
lermészetesen amod per1 csodájának fénye némileg meg- 
kopik, amint a grafikus tervezők is színre lépnek. A tervezők 
nem igazán szeretnek kódot szerkeszteni, valahányszor meg- 
változtatják a stílust (vagy a tartalmat) az adott lapon, és ha 
rászabadítjuk őket a Perl-modulok forráskódjára, abból nem 
sok jó származik. Így aztán különféle sablonrendszerek tucatjai 
születtek, amelyek mindegyike valamilyen módon képes ke- 
verni a Perl és HIML nyelvet. Az egyik legnépszerűbb közülük 
a Mason, amely tudását az évek során már számos komoly 
terjesztő honlapon keresztül bizonyította. 

A Mason valóban csodálatos eszköz, ami kitűnő egyensúlyt 
teremt a gyors fejlesztés (a Perlnek köszönhetően), a könnyű 
karbantarthatóság (a Masonnek hála) és (a mod per1 érde- 
meként) a gyors végrehajtás között. A Mason-levelezőlistától 
előnyös tájékoztatást és jó támogatást várhatunk, a csomag 
fejlesztőinek munkája pedig csodálatra méltó, mivel az idők 
során folyamatosan tökéletesítették programjukat. A Mason 
korszerű változatainak beállítását, használatát és hibakeresését 
látva azok az első változatok, amelyeket pár évvel ezelőtt 
először használtam, kezdetlegesnek tűnnek. 

A Mason egyben háttér és keretrendszer, amelyben saját 
alkalmazásainkat készíthetjük el. Igaz ugyan, hogy az 

Apache : : Session felhasználásával könnyedén készíthetünk 
sütiket és egyszerűen rendelhetünk a felhasználókhoz egyedi 
azonosítókat, de a kiforrott alkalmazásokban megtalálható 
felhasználói feliratkozás, a csoportok és a jogosultságok 
rendszerét mind magunknak kell megvalósítanunk. Néhány 
projektben ez a megfelelő megoldás, hiszen a szükséges 
rugalmasságot kínálja. Ha azonban már ötödjére kapjuk azon 
magunkat, hogy ismét egy felhasználókat és jogosultságokat 
kezelő rendszert készítünk, esetleg úgy dönthetünk, hogy egy 
kicsit több hátteret nyújtó lehetőséget választunk. 
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Java és J2EE 

A Sun már jó néhány éve hirdeti kiszolgálóoldali megoldásként 
a Javát. A JEE (Java 2, Enterprise Edition) elnevezés egy olyan 
gyűjtőfogalom, amelybe több, a fejlesztőket ilyen megoldások 
kialakításában segítő különféle módszer tartozik. A servletek 
olyan osztályok, amelyek a kiszolgálón valósítanak meg kódot; 
a JavaServer Pages (JSP-k) olyan Java/HTML-sablonok, amelye- 
ket futásidőben fordítunk servletté. A JDBC-illesztő adatbá- 
zisok elérését teszi lehetővé, míg az Enterprise JavaBeans a 
tranzakciókat és az önműködő relációsobjektum-átalakítást 
kezeli. Ahhoz, hogy a Java világába beléphessünk, rengeteg 
rövidítést és módszert kell megismernünk, valamint több kü- 
lönféle szabvány számos változatát elsajátítanunk. 

Amióta először megjelent, többször dolgoztam már Javával, 

s szinte minden esetben arra jöttem rá, hogy hiába szeretném, 
hogy érdekeljen, képtelen vagyok rávenni magamat a megked- 
velésére. A Java önmagában nem rossz, és a különféle módsze- 
rek, amiket letesz az asztalra, mind igen lenyűgözők. A servle- 
teket könnyű elkészíteni; a JSP-k (különösen a JSP-khez készít- 
hető egyedi tagok) érett és figyelemre méltó sablonrendszert 
alkotnak, végül a JDBC mindent biztosít számunkra, amit egy 
adatbázis-kezelő felülettől valaha is elvártunk. Igaz ugyan, 
hogy az EJB használata a legtöbb projektben kétségtelenül 
túlzás, ugyanakkor hihetetlen hasznos lehet azokban a nagy 
fejlesztői csoportokban, amelyeknek a Sun eredetileg szánta. 
lovábbá számos jó megvalósítás, köztük kitűnő nyílt forrású 
alkalmazáskiszolgálók és eszközök születtek, ami mindenkép- 
pen lenyűgöző és ösztönző erőt képvisel. 

Úgy tűnik, hogy a webfejlesztés világának ,nagycége" a Java 
lett. A dolgokat megbízhatóan oldja meg, rengeteg képesség 
rejlik a tarsolyában, és számos szabványt támogat, fejlesztőesz- 
közök seregei állnak a rendelkezésünkre — és meglehetősen sok 
ember használ Javát. Csak éppen a Java-projektekkel járó 
pluszmunka egy kicsit sok az én ízlésemnek. Már az is hosszú 
időt vesz igénybe, ha csak azt szeretnénk megállapítani, hogy 
melyik szabvány melyik változata melyik Jakarta alprojekt 
melyik változatához való. Ahogy sokkal érdekesebb kis cégnek 
dolgozni, mint nagynak, ugyanúgy sokkal érdekfeszítőbb sze- 
rintem Perl vagy Python alatt programozni, semmint Javában. 
Ráadásul a J2EFE hasonló gondoktól szenved, mint amelyeket 

a mod perl és a Mason esetében leírtam, nevezetesen, hogy 
tisztán csak hátteret ad, anélkül, hogy bármi figyelmet szentel- 
ne a beépített alkalmazásoknak. A fejlesztők csodálatos dolgo- 
kat hozhatnak létre, de minden projektben mindent újra ki kell 
fejleszteniük. 

Talán a legjobban azt kedvelem a Java világában, hogy olyan 
nagy figyelmet fordít a karbantartható és megbízható progra- 
mokra. Jó néhány próba- és fejlesztőeszköz, többek közt az 
Ant, a Cactus, a JUnit és a log4j lehetővé (sőt talán magától 
értetődővé) teszi, hogy a programozók teljes körű teszteket 
végezzenek a program kiadása előtt. 

lehát akkor a Java jó választás a webfejlesztéshez? Véleményem 
szerint minél nagyobb projekten dolgozunk, annál inkább 
érdemes elgondolkodnunk a Javán mint lehetőségen. De a 
klasszikus kis webalkalmazások esetében, amelyekkel a kis 
műhelyek dolgoznak, a fejlesztéshez kapcsolódó elkerülhetet- 
len többletmunka túlságosan komoly tényező, amit már nem 
hagyhatunk figyelmen kívül. 


Zope 

A Zope ékes bizonyítéka annak, hogy a nyílt forrású programok 
nem csak másolják kereskedelmi versenytársaikat. A Zope az 
objektum-adatbázist ötvözi a többprotokollú kiszolgálóval, to- 
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vábbá gazdag objektumkészlettel és gördülékeny webalapú ke- 
zelőfelülettel ruházza fel őket. A Zope újító jellegű, okos, öröm 
vele dolgozni, és azon ritka nyílt forrású programok közé tarto- 
zik, amelyet a felhasználóknak terveztek, tehát nem csak a kód- 
lovagoknak szól. A grafikusok örömmel hallják, hogy lehetősé- 
gük nyílik a dokumentum bármely korábbi állapotához vissza- 
térni, a webalapú kezelőfelület , vissza" (undo) képességével. 

A Zope több programozói felülettel is rendelkezik, amelyek a 
hatékonysággal szemben az egyszerűséget részesítik előnyben. 
Egyszerű DIML-sablonokat és Python-parancsfájlokat készít- 
hetünk, használhatjuk az elbűvölő ZPI sablonokat, amelyek 
teljesen elválasztják egymástól a programot és a megjelenítési 
logikát, vagy végigjárhatjuk a teljes utat és egy új Zope-termé- 
ket készíthetünk. Az igazi erő a Zope-termékekben rejlik. 
Mivel minden termék egyben egy osztály is, különféle címeken 
egyetlen termékből több példányt is létrehozhatunk. Mivel az 
objektumok saját objektumrendszereiken kívül a címrendszer 
alapján is örökölnek (szerzeményezés), a példány jogosultsá- 
gai, viselkedése vagy a kinézete címenkért eltérő lehet. 

No, ez eddig úgy hangzott, mintha a HIITP óta a Zope lenne 

a legjobb dolog, ami a Weben megjelent. Valóban, a Zope-kóde- 
rek növekvő száma egyben azt is jelenti, hogy egyre több 
ingyenes letöltés lesz elérhető és egyre több kereskedelmi 
termék használja alapjául a Zope-ot. 

Sajnos a Zope-nak is megvannak a maga hibái, az első és 
legnagyobb az, hogy a tanulási görbéje igencsak meredek 
lehet. Mégha tapasztalt webfejlesztő is valaki, a Zope megkö- 
veteli, hogy majdnem az összes elgondolást az alapoktól újra 
megtanulja, megváltoztatva szinte minden szokást, amit az 
évek során összeszedett. Ez nem feltétlenül káros dolog, hiszen 
a Zope-ban elég jó megoldásokat találunk, de meglepetést 
okozhat és óvatosságra késztethet, egyszerűen azért, mert a 
Zope felhasználása a kezdeti, induló időszakban kétségtelenül 
lelassítja a dolgokat. 

A másik gondom a Zope-pal az objektum-adatbázis alapja. 

Az objektum-adatbázisoknak hagyományosan több nehéz- 
ségük is akad, és a ZODB szépen követi is ezt a hagyományt. 
Ugyanakkor a relációs adatbázisok még mindig elég általá- 
nosak, az emberek gyakran erre számítanak (általában meg is 
követelik). Elméletben ez sem gond. A Zope beépített ZSOL 
tagfüggvényei lehetővé teszik, hogy mindenféle különösebb 
erőlködés nélkül látványos dolgokat műveljünk a relációsadat- 
bázis-lekérdezésekkel. A gond akkor válik nyilvánvalóvá, 
amikor az adat két különféle hely között oszlik meg: a ZODB 
és a relációs adatbázis között. Én például az összes adatomat 
egyetlen központi helyen szeretem tartani, így aztán ez a fajta 
megosztás számomra eléggé kiábrándító. 

Azután ott van a sebesség kérdése: a Zope kifinomult jogosult- 
ság- és szerzeményezésrendszere valószínűleg gyorsabb, mint 
ahogy te vagy én magunktól meg tudtuk volna írni, de még 
így is elég lassúcska. A nehézség hivatalos Zope-megoldása 

a ZEO (Zope Enterprise Objects), amely lehetővé teszi, hogy 
egyetlen objektumadatbázist egyszerre több Zope-kiszolgáló is 
elérhessen. Jelenleg napi egymillió találatot bír el, ami a legtöbb 
lapon , amin dolgoztam, több mint elég. A különlegesen nagy 
webhelyek készítői azonban már aggódhatnak a Zope gyorsa- 
sága miatt, vagy másik megoldásként tervbe vehetik egy 
felsőkategóriás vas megvásárlását a ZODB kiszolgálóhoz. 
Végül: a Zope-termékek többnyire függetlenek. A jó hír ebben 
az, hogy a fejlesztők párhuzamosan, a másik akadályozása 
nélkül tudnak dolgozni. A rossz hír, hogy a dolgok nincsenek 
annyira egységesítve, mint kellene: egységes irányítás nélkül 

a szolgáltatások ismétlődnek. Lehet, hogy egy ilyen méretű 
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nyílt forrású projekt esetében ez már elkerülhetetlen, minden- 
esetre kicsit kiábrándító. 

Az utóbbi egy-két évben a Zope Corporation az alkalmazás- 
fejlesztés helyett a tartalomkezelés területén kezdte el reklá- 
mozni a Zope-ot. lermészetesen minden tartalomkezelő rend- 
szert újra kell programozni és módosítani kell a vásárló igé- 
nyeinek megfelelően, így a különbség nem annyira szembe- 
tűnő. Bár a Zope nem az egyetlen nyílt forrású tartalomkezelő 
rendszer a piacon, kétségtelenül az egyik legkifinomultabb és 
egyben az egyik legkiforrottabb is. 

Saját munkáim esetében akkor választom a Zope-ot, ha az 
ügyfél projektje jelentős mértékű trükkös fejlesztést igényel, 
vagy ha viszonylag egyszerűen használható felhasználói felü- 
letet szeretne, illetve ha tartalomkezelésről van szó. lovábbra 
is nagyra tartom, és valószínűleg az elkövetkező években is 
elég sokat dolgozom majd a Zope-pal. 


OpenACS 


Az OpenACS a születésekor közösségi weblapokhoz tervezett 
kifinomult adatmodell volt, számos TIcl nyelven írt web-, illetve 
adatbázissablonnal kiegészítve. Idővel aztán egy sokkal na- 
gyobb, sokoldalúbb projektté nőtte ki magát: független csoma- 
gokkal rendelkezik, amelyek a programot és az adatmodellt 
egyaránt képesek frissíteni, zökkenőmentesen képes együttmű- 
ködni az Oracle vagy a PostgreSOL rendszerekkel, és kifino- 
mult sablonozórendszert tartalmaz, amely a kódot elválasztja 

a HIML-kimenettől. Iovábbá az OpenACS rengeteg előre elké- 
szített alkalmazással érkezik, amelyek szinte bármit képesek 
megoldani, amire csak egy közösségi weboldalon szükségünk 
lehet -— a webnaplóktól kezdve a gyakran ismételt kérdéseken 
át egészen az e-boltig. Igen rövid idő alatt elkészíthetünk egy 
weboldalt, s ehhez semmi mást nem kell használnunk, kizá- 
rólag a böngészőnket. 

Mindig az OpenACS-t ajánlgatom azoknak a nonprofit szerve- 
zeteknek, akik hálózati közösségeket akarnak létrehozni, el 
akarják érni a tagjaikat, le akarják bonyolítani a tagok közti 
vitákat, vagy egyszerűen adatokat szeretnének közölni a 
módszer mélyebb ismerete nélkül. 

Azt mondják, az OpenACS több gonddal is küszködik. Az első 
és legfontosabb a tanulás. A Zope megismerése elég nehéz, hi- 
szen oly sok módszert szükséges megérteni hozzá. Az Open- 
ACS sokkal egyszerűbb modellel bír, de az égvilágon mindent 
relációs adatbázisban tárol. Noha ez azt jelenti, hogy minden 
adat egy helyen van, a relációs adatbázisok hírhedten rosszak a 
rendszerkezelésben és a világ összes okos OpenACS-fejlesztője 
sem képes ezt kiküszöbölni. 

Így aztán, az OPpenACS-csel való munkához meg kell tanul- 
nunk, hogyan készíthetünk egyszerű objektumöröklési modellt 
és a hozzátartozó teljes körű felületet, ami elérhetővé teszi. 

Ha még soha nem készítettünk tárolt eljárásokat, vagy nem 
dolgoztunk olyan adatbázissal, ami táblák tucatjait vagy százait 
tartalmazza, lehet, hogy az OpenACS-hez szükséges háttér- 
tudás végül letaglóz minket. 

Az OpenACS másik nehézsége, hogy csak kevés leírás áll a 
fejlesztők rendelkezésére és jótormán semmi a végfelhasználók 
számára. Az OpenACS kétségkívül összetett rendszer, amelyet 
egy szakmán kívüli ember számára elég nehéz leírni, de 
meglehetősen bosszantó, ha semmilyen segítséget sem találunk 
a témában. Becsületükre legyen mondva, a fő openacs.org 
honlapot mostanában modellezték és írták újra, röviddel aze- 
lőtt, hogy ezt a cikket megírtam volna, és úgy tűnik, e tekintet- 
ben is akad néhány kedvező változás. 

Végezetül kicsit ironikusnak találtam, hogy az OpenACS egyre 
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lomhábbá vált az idők folyamán. lalán elfogadható érv, hogy 
ez amiatt történt, mert a legfrissebb változat (e sorok írásakor a 
4.x) sokkal többet tud a felhasználók, csoportok és engedélyek 
témakörében, mint az elődei, és ezek ellenőrzése minden 
HITTP-kérelemnél időt vesz igénybe. Ezen felül a fejlesztők is 
tudják, hogy sok javítást még végre lehet hajtani ahhoz, hogy 
ne igényeljen minden kérelem olyan sok adatbázis-lekérdezést. 


Összegzés 

Néhány nappal a cikk megírása előtt megjelent a Weben egy 

új hír arról, hogyan ültették át a Yahoót PHP webprogramozási 
környezet alá. Én személy szerint más nyelvekkel szeretek 
dolgozni, és nem éreztem volna nagy kedvet, hogy a teljes 
Yahoót új nyelven írjam újra. De a Yahoo egyedi igényeinek 
megfelelően úgy tűnik, hogy a PHP tényleg jó választás. 
Kapnak egy jó pontot tőlem, amiért végiggondolták az összes 
lehetőséget, mérlegelve az előnyöket és hátrányokat, míg végül 
megkapták azt, ami leginkább illik az igényeikhez. 

Ahogy már a cikk elején is írtam, mélyen hiszek abban, hogy 
mindig meg kell keresni azt a módszert, ami az adott feladat 
szerint igényekhez a legjobban igazodik. Nekem, a fejlesztőnek 
ez azt jelenti, hogy folyamatosan új nyelveket, módszereket 
kell megismernem és elsajátítanom; ugyanakkor azt is magá- 
ban foglalja, hogy az ügyfeleim olyan megoldásokat kapnak, 
amelyek illeszkednek a feladataikhoz, és én mint programter- 
vező széles körű és mélyebb tudást gyűjtök. 

Az a tény, hogy ezek a rendszerek az Interneten ingyenesen 
hozzáférhetők, azt mutatja, hogy az egyetlen akadályt csak 

a ráfordított idő és erőfeszítés képezheti. Mindenkit arra buz- 
dítok hát, hogy szorítson egy kis időt a kipróbálásra - te is és 

a veled dolgozó emberek is kétségtelenül értékelni fogják az 
eredményt. 


Linux Journal 2003. február, 103. szám 


Rewven M. Lerner (reuvenelerner.co. 11) 

Egy kisebb webes és internetes módszerekkel 
foglalkozó tanácsadó cég tulajdonosa és 
vezetője. Az AIF honlapon érhető el 

(2 http:Avww.lerner.co. il/atf/). 








A mod perl1-ről a 3 http://perl.apache.org lapon, a 
Masonről pedig a 3 http://wwvw.masonha.com lapon 
olvashatunk. 


A JZ2EE témával mélyebben a 5 http://java.sun.com 
foglalkozik. Az Apache Software Foundation Jakarta 
Projektje a nyílt forrású Java programhoz a 

2 http://jakarta.apache.org címen lelhető fel. 


A Zope főlapja a 3 http:/Avww.zope. org. Akik újak 

a Zope-témában, nézzenek el a 

2 http:/Avww.zopenewbles.net lapra; a nagyobb tudású 
felhasználók a 3 http:/Awww.zopezen.org-ot keressék. 
Végül az OpenACS közösséget az 

2 http:/Avww.openacs.org címen érhetjük el. 

A PostgreSOL adatbázist, amelyet az OpenACS-hez hasz- 
nálhatunk, a 3 http:/Avww.postgresal.org címen találjuk. 
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Grafikonon a vállalkozás 





A bemutatásra kerülő nyílt forráskódú eszközök segítségünkre lehetnek abban, 
hogy nyomon követhessük bármilyen vállalkozásunk alakulását. 


tt van, Francois, a Collins-szótár 509. oldalán. A vállalkozás 
[ — ami e havi beszélgetésünk témája — a francia entreprise 

szóból származik. Látod, mon ami, úgy van, ahogy mond- 
tam neked: a meghatározás szerint ez olyan projektet vagy 
vállalkozást takar, amely merészséget vagy erőfeszítést igényel. 
Manapság legtöbbször valamilyen üzleti tevékenységet folytató 
szerveződést értünk alatta. Ettől függetlenül a meghatározás így 
is megállja a helyét. 
Az emberek naponta vágnak bele újabb és újabb feladatok 
megoldásába (különféle projekteket indítanak, ha így jobban 
tetszik). Ezeknek a vállalkozásoknak a sikere gyakran szoros 
kapcsolatban áll azzal, hogyan irányítják őket, mennyire körül- 
tekintő a tervezés, és milyen gondosan követik a folyamatokat. 
Mon Dieu, Francois! Miért nem szóltál, hogy már ilyen késő van? 
Már megg is érkeztek a vendégeink. Bonjour, mes amis, isten ho- 
zott titeket Chez Marcelnél, a kitűnő Linux-konyha és az ellenáll- 
hatatlan borok otthonában. Francois! Hozd fel, kérlek az 1996-os 
South Australia Coonawarra Shirazt, immédiatement! 
Ahogy épp Francois-nak magyaráztam az imént, mai menünk 
középpontjában az új, vakmerő projektek indítása, vagyis a 
vállalkozás áll. Egy vállalkozás elindításának nyilvánvaló 
tűnik egy nagy projekt pillanatnyi állapotának a feltérképezése 
is. Ezt általában Gantt-grafikonokkal végzik, amelyet Henry L. 
Gantt fejlesztett ki 1917-ben. A jól ismert vízszintes oszlop- 
grafikont fejlesztette tovább könnyen használható termelés- 
irányítási eszközzé, vizuális eszközt biztosítva egy projekt 
állapotának ábrázolására, és ezzel nagymértékben egyszerű- 
sítve a munkafolyamatok nyomon követését és az irányítást. 
Nézzük, hogyan is működik. A Gantt-grafikon vízszintes ten- 
gelye a folyamatra szánt időt ábrázolja. Ez felosztható napokra, 
hetekre, vagy bármilyen más időegységre, ami az ábrázolás 
szempontjából ésszerű. Gondoljunk arra, hogy egy projekt 
rettentő hosszú ideig is eltarthat. A függőleges tengelyen a 
munkafolyamatot felépítő feladatok vannak felsorolva. Például 
nemrégiben fel kellett töltenem a raktárkészletemet itt, Chez 
Marcel borospincéjében. A munka ebben az esetben leltározás- 
ból (Francois), egy kis polcátszervezésből (Francois és Chef 
Marcel), szállításból (Henri of Henris Fine Wines) és végül 
a raktár újrafeltöltéséből állt (Francois). 
Ha már Francois-nál tartunk, az én nagyrabecsült pincérem visz- 
szaérkezett a pincéből. Francois, tölts kérlek a vendégeinknek! 
Ez a Coonawarra Shiraz biztosan ízleni fog, mes amis. A Shiraz 
hagyományos zamata mellett észrevehettek egy kis csokoládé 
ízt a bukéjában, és talán egy kis mentát is. És ez az íz... Bocsá- 
nat, elkalandoztam egy kicsit, a Gantt-grafikonokról volt szó. 
Az egyes feladatokat különböző hosszúságú (esetleg más-más 
színű) vízszintes sávok jelölik, ahol a hosszúság az adott 
feladathoz szükséges időt mutatja. A projekt bármelyik pontján 
húzható egy függőleges szakasz a grafikon tetejétől kezdő- 
dően, amely jelentésül szolgál arról, hogy a munkafolyamat 
éppen milyen állapotában van. Egyszerű, nem? 
Az egyszerűség az a gondolat, ami a Graphical UI Gantt Chart 
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Generator (az eredetileg Jason R. Govig és Seth Goldstein által 
karbantartott, pillanatnyilag Glen Stewart fejlesztése alatt álló 
program) alapeszméje. Ez a Gantt-grafikonok előállítására hi- 
vatott webalapú rendszer egyszerűen CGI parancsfájlok gyűj- 
teménye. Tökéletesen megfelel a célra, ha könnyen használ- 
ható, hálózati munkára alkalmas ábrázolóprogramot keresünk. 
A működéséhez szükségünk van az Apache-ra és két Perl- 
modulra, ezek a CGI . pm és a Date : : Manip . pm. Ezeket a 
Perl-modulokat legegyszerűbben a CPAN paranccsal telepít- 
hetjük, a parancssorból: 


perl -MCPAN -e "install Date: :Manip" 
perl -MCPAN -e "install CGI" 


Hozzá kell tennem, hogy mindezt rendszergazdai jogosultság- 
gal kell elvégeznünk. Ha korábban még soha nem használtuk 
a CPAN parancsot Perl-telepítésre, akkor több kérdésre is 
felelnünk kell majd a beállításra vonatkozóan. Ezt a beállítást 
csak egyszer kell megtennünk, onnantól kezdve a telepítés 
teljesen zökkenőmentes folyamat. A csomag használatához 
böngészőprogramunkba írjuk be a a megfelelő címet. Az én 
rendszeremen ez valahogy így fest: 5 http:/webserver/gantt/. 
A Gantt-grafikon csomag forrása az 

2 http:/associate.com/gantt honlapon érhető el. Először 
csomagoljuk ki a forráskódot webkiszolgálónk dokumen- 
tumkönyvtárának gyökerébe: 


tát szvit gantt-il.0 tat. gz 
mv gantt-1.0 gantt 


Az egyszerűbb kezelhetőség kedvéért én rögtön átneveztem 

a könyvtárat. Bármilyen nekünk tetsző nevet választhatunk. 
Vessünk egy pillantást a distribution könyvtár alatt lévő 
könyvtárakra, különös tekintettel a /users-re! A felhasználónak, 
ami alatt az Apache-ot futtatjuk (az én rendszeremen ez a 
www), a teljes könyvtárra írási joggal kell rendelkeznie. 
Keressük meg a felhasználót és a csoportot a httpd.conf fájlban. 
Néhány változtatásra is szükségünk lesz, ami leginkább két 
állományt érint. Az első a variables.pl nevű fájl. A megváltoz- 
tatandó sorok a saját oldalunk beállításai, nevezetesen a doku- 
mentumgyökér (amelyről fentebb már volt szó), a grafikon- 
készítő címe, a rendszert felügyelő neve és elektronikus 
levélcíme: 


H full path to site on server 


Sdocroot - " /usr/1local/apache/htdocs/gantt/ " ; 
H URL of site 
Swwwroot - 


5" http: //webserver . vourdomain . dom/gantt / " ; 
H Name of site administrator 

Sadmin - "Your Name" ; 

H Email of site administrator 

SsadminEmail - "your emailgyourdomain.dom" ; 


Egy kis módosításra lesz szükség a dbhelp.pl fájlban is: meg 
kell adnunk a variables.pl elérési útvonalát: 


B Edit this to boint to the location of yvour 
H variables.pl file 

reguire 

" /usr/local/apache/htdocs/gantt/variables.pl!" ; 


Végül az Apache kiszolgáló httpd.conf állománya kíván meg 
egy kis szerkesztést. Engedélyeznünk kell a CGI parancsfájlok 
futtatását a gantt könyvtárából (ami a dokumentumok könyv- 
tárából nyílik), amihez a következő szakaszhoz hasonló 
bejegyzésre van szükség: 


cDirectory "/usr/local/apache/htdocs/gantt": 
Options ExecCGI 
c/Directoryz 


A webkiszolgáló újraindítása után (apachectl graceful) a rend- 
szer működésre kész. 

A Gantt grafikonkészítő használatához gépeljünk be egy nevet 
a bejelentkezési mezőbe - bár az ablak elektronikus levélcímet 
vár, bármilyen egyedi név megteszi. Ha ez az első alkalom, 
hogy a programot futtatjuk, egy párbeszédablakot kapunk, 
amelyben a nevünket és elérhetőségünket kell megadnunk. 

A Submit (elküld) gomb megnyomása után megadhatjuk 

a projektünk adatait és a benne résztvevő tagokat. 

Ezután felsoroljuk azokat a feladatokat, amelyek végrehajtása 
elvezet a vállalkozás sikeres befejezéséhez. Minden sor külön 
színkóddal rendelkezik. Bármikor lehetőségünk van további 
feladatok felvételére. Az oldal minden módosítása a feladat kez- 
dő és befejező hetének és a végrehajtásért felelős személynek a 
meghatározásából áll. Amikor befejezésképpen a Submit gombra 
kattintunk, a program a grafikonot önműködően létrehozza. 
Egy másik, a figyelmünkre érdemes projekt, a MrProjekt 

(2 http:/mrproject.codefactory.se). A Gnome Office részét 
képezve ez már a munkaasztaloz kötődő alkalmazás, így lehet, 
hogy semmit sem kell tennünk, ha a Gnome felhasználói felü- 
letként már telepítve van a gépünkön (esetleg akkor sem, ha 
nincs). A MrProject megtalálható a legutóbbi Mandrake, Red 
Hat, SuSE és a többi Linux-rendszercsomag telepítőlemezein. 
Amikor az mrproject 6 paranccsal első alkalommal indítjuk 
el a MrProjectet, egy üres projektet nyitunk meg. A New (új) 
gombra kattintva egyszerre több projektet is megnyithatunk. 
A bal oldalon találhatjuk meg a Resources (erőforrások), a Gantt 
Chart (Gantt-grafikon) és a Tasks (feladatok) gombokat. Az 
egyik nézetből a másikba való átkapcsolás egyszerűen ezeknek 
a gomboknak a megnyomásával történik. 

Egy új folyamat elindításakor a menüsor File (fájl) menüjének 
Project Properties (a projekt jellemzői) menüpontot kell 
kiválasztanunk. Írjuk be a folyamat nevét, a kezdés dátumát 
(ezt a MrProject egy barátságos legördülő naptárral segíti), a 
vezető nevét és a szervezetre vonatkozó adatokat. Kattintsunk 
a Close (bezár) gombra, és mentsük a projektet valamilyen 
tetszőleges értelmes néven. 

A következő lépésünk a folyamat során rendelkezésünkre álló 
erőforrások rögzítése lehet. Ezt az erőforrások megjelenítésével 
(Resources), majd az Insert (beszúrás) gombra való kattintással 
érhetjük el. Ezzel egy alapértelmezett erőforrásrekordot ve- 
szünk fel a listára, ami egy jobbegérgomb-kattintással szer- 
keszthető. Az erőforrás lehet valamilyen anyagi természetű 
dolog vagy időráfordítás. Költséget is itt tudunk megadni. 

A feladatok rögzítéséhez az oldalsó gombsorról a Tasks feliratút 
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kell választanunk, ezután az Insert-et. Az erőforrásokhoz 
hasonlóan itt is egy általános feladatot kapunk, amit be kell 
állítanunk. Ezek a feladatok tetszőleges módon leírhatók, majd 
erőforrásaink egyikéhez rendelhetők. A feladatok beírásának 
sorrendjével nem kell foglalkoznunk, a végrehajtási sorrend 
utólag bármikor megváltoztatható oly módon, hogy a feladatot 
a listából kiválasztva a Move up (mozgatás felfelé) vagy a Move 
down (mozgatás lefelé) menüpontra kattintunk. Az egy fela- 
dathoz rendelt idő napokban kerül kifejezésre, de törtnapok 
beírására is lehetőségünk nyílik. A feladat végrehajtásának 
százalékos értékét is itt rögzíthetjük. 

Bármelyik munkafázisban átválthatunk a Gantt nézetre. 
Elegáns megoldás, hogy a feladatok idejét a vízszintes sávra 
való kattintással és húzással módosíthatjuk. (Azt hiszem, több 
időt kell a , Borkóstolás és minőségellenőrzés" feladatához 
rendelnem.) Feladatfüggőségek szintén bármikor hozzáad- 
hatók, hiszen könnyen előfordulhat, hogy egy feladat elkez- 
déséhez egy másiknak előbb be kell fejeződnie. 

Ez csak két példa azokból a programcsomagokból, amelyekkel 
lehetőségünk nyílik a projektek kezelésére, nyomon követésére 
és ábrázolására. Ha kíváncsiak vagyunk arra, hogy milyen 
egyéb eszközök elérhetők el a Világhálón erre a célra, ajánlom 
a , Call Center, Bug Iracking and Project Management Tools for 
Linux" (lelefonos ügyfélszolgálati, programhiba-kereső és 
projektkezelő eszközök Linuxra) című oldal meglátogatását 

(2 http:/wwwi.linas.org/linux/pm.htm)]). 

Keressük meg az oldalon a Project Management (folyamatke- 
zelés), vagy akár a Schedulers (ütemező programok), Planners 
(tervezőeszközök), Gantt Chart Tools (Gantt-grafikon készítők) 
című részeket, ha ezekhez hasonló csomagokat szeretnénk 
további vizsgálatoknak alávetni. Az ajánlatok között egyformán 
szerepel szabadon felhasználható, illetve kereskedelmi termék, 
és minden csomaghoz megtalálható annak tömör leírása, 
valamint a honlapjára mutató hivatkozás. 

Most látom csak, hogy a poharaitok majdnem üresek. Kérjük 
meg Francois-t, hogy gyorsan orvosolja ezt a nehézséget. 

A következő havi viszontlátásig ürítsük poharunkat egymás 
egészségére. A votre santé! Bon appétit! 


A cikkben szereplő programok a 45. CD Magazin/ Fogado 
könyvtárában találhatók meg. 


Linux Journal 2003. február, 103. szám 


Marcel Gagné (mggagneosalmar.com) 
Mississaguában, Ontario államban él. Ő a szerzője 
a Kiskapu kiadásában szeptemberben megjelent 

L inux-rendszerfelügyelet (ISBN 96-9301-40) című 
könyvnek (jelenleg Is egy könyvön dolgozik). 





Call Center, Bug Iracking and Project Management 
Tools for Linux 5 http:/Awvvwwvv.linas.org/linux/om.html 
Graphical UI Gantt Chart Generator 

2 http://associate.com/gantt 

MrProject 3 http://mrproject.codefactory.se 
Marcels Wine Page 

2 http:/Avww.marcelgagne.comAwine.htmi 
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Veled vagy nélküled? 


A Treo 1809 mobiltelefon és zsebtitkár (Siemens "45). 


ostanában a mobiltelefonokat már nem az alapszol- 
gáltatásukért vesszük meg, hanem elsősorban a ki- 
nézetük, másodsorban pedig a pluszszolgáltatásaik 
miatt. Az már fel sem merül bennünk kérdésként, hogy vajon 
az alapszolgáltatásokat (hívásfogadás és -kezdeményezés, netán 
SMS-küldés és -fogadás) megbízhatóan (fagyásmentesen) képe- 
sek-e számunkra biztosítani. A válasz 98 százalékban ,nem 
tudja" lenne. Ki ne találkozott volna olyan Nokia 6210-essel, ami 
három hónapos korában fogja magát, és egyszerűen kikapcsol- 
gat. Egy átlagos telefon többet van garanciális szervizben, mint 
kellene. Én még emlékszem olyan esetre is, amikor Nokia 2110-es 
telefonomat beszélgetés közben elejtettem a lépcsőházban. 

A telefon komótosan, minden lépcsőfokot érintve leballagott 

a második emeletről a földszintre, és amikor felvettem, még a 
beszélgetőpartnerem is a vonalban volt. Nos, az a telefon szinte 
sose fagyott le. Igényeink azóta nagyot fejlődtek, manapság egy 
átlagos tízezer forintos akciós telefonnal nagyobb sávszélesség- 
gel lehet internetezni, mint annak idején egy internetes gerin- 
cen ülve. Bevallom, engem egy kicsit mindig is zavart, hogy a 
telefonom, a Palmom és a linuxos gépem között folyamatosan 
össze kell hangolnom a telefonszámaimat és egyéb adataimat. 
Így amikor a Handspring cég megjelent az első olyan Palm 
operációs rendszert futtató gépével, amely 900/1800-as telefon 
is egyben, nagyot dobbant a szívem. Nekem kell egy ilyen! 

Be is szereztem egyet azonnal, és bár ne tettem volna! 


Treo 1809 

A Ireo 1808 szolgáltatásait tekintve egy 3.5.1-es Palm OS-t 
futtató tenyérgép, amely 16 MB belső RAM-mal rendelkezik, 
és kapott egy 900/1800-as Visor phone nevű bővítményt. A régi 
változatokkal ellentétben itt egybeépítve található a telefon, 
így egy igen mutatós flippes telefonnál , alig" nagyobb. Palmos 
és a linuxos kapcsolódási lehetőségének előnyeit kihasználva 

a már meglevő Palmomról olyan módon tudtam a programokat 
az új gépre áttelepíteni, hogy egyetlen programot sem kellett 
újra beállítanom. Ahol a Palmon elengedtem a tollat, a Visoron 
ott került újra elő. A Ireo 180g-hez a gyári csomagolásban 
rendkívül gyakorlatias módon nem egy dokkoló állomást 
adnak, hanem egy olyan USB-csatolókábelt, amelybe az úti 
töltő külön is becsatlakoztatható. Nézzük, mit is kell tennünk, 
hogy Linux alatt munkára bírjuk a Ireót! 





A Treo beállítása 

A 2.2.2x-es, illetve a 2.4.x-es rendszermagok mindegyike 
tartalmaz az USB menüpont alatt egy USB Serial Converter 
Support menüt. Nos, itt a következőket kell beforgatni: 


CONFIG USB SERIAL-y 
CONFIG USB SERIAL GENERIC-y 
CONFIG USB SERIAL VISOR-m 


A legtöbb asztali felhasználásra szánt Linux-terjesztést olyan 
,gyári" rendszermaggal szállítják, amihez hozzá sem kell nyúlni. 
Jobb esetben, amikor az eszközt bedugjuk az USB-csatlakozóba, 
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betölti a megfelelő modult és 
már használható is. A memó- 
riaadapterekkel ellentétben a soros USB-eszközök akkor láthatók 
Linux-oldalról, amikor az eszköz kapcsolatot kezdeményez. 

Ha tehát a Visor oldaláról elindítjuk az összehangolást, jobb 
esetben a /var/log/messages állományban hasonlót fogunk látni: 


Jan 22 12:26:29 timeout kernel: usbserial.c: 
Handspring Visor converter detected 
Jan 22 12:26:29 timeout kernel: visor.c: 
Handspring Visor: Number of ports: 2 
Jan 22 12:26:29 timeout kernel: visor.c: 
Handspring Visor: port 1, is for Generic use 
and is bound to 

ttyUSBO 
Jan 22 12:26:29 timeout kernel: visor.c: 
Handspring Visor: port 2, is for HotSync use 
and is bound to 

ttyUSB1 


Ha mégsem ezt látjuk, célszerű megpróbálkoznunk a visor.o 
modult betöltésével, amit az insmod visor paranccsal tudunk 
megtenni. Ha ez nem sikerülne, jöhet a rendszermagfordítás. 

A kapcsolattartás a Linux oldaláról — a Linuxvilágban már több- 
ször bemutatott pilot-1link, illetve a jpilot (grafikus) 
programok segítségével lehetséges. 

A Visor oldalán a system panell/preferences/ Connection alatt 
célszerű egy új csatlakozást készíteni, ugyanis a gyári beállítá- 
sokkal az USB sebessége csak 56 K-ra van levéve, és ezt nem is 
engedi megváltoztatni. Ha azonban felveszünk egy csatlako- 
zást, annak akár 230 400 b/s5-t is beállíthatunk. Fontos azonban, 
hogy a Linux oldalán is ugyanaz a csatlakozási sebesség legyen 
beállítva, mert eltérő sebességű adatátvitelnél igen érdekesen 
működhet. Mindezek beállítása után a már meglévő adatain- 
kat, illetve az újakat is egy mozdulattal telepíthetjük. 

Nézzük a , telefont": a beépített kétnormás (900/1800) GSM 
szabványú telefon első használatra elég fapadosnak mondható. 
Mivel azonban a legtöbb dobozos Ireo alapesetben amúgy 

sem tudja a GPRS-t, a GPRS-frissítést érdemes letölteni a 
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2 http:/www.treogprs.com címről. Ez aztán nemcsak GPRS- 
képessé teszi majd kézi mindenesünket, hanem egy csomó 
további szolgáltatást is elérhetővé tesz a GSM terén. Ezenkívül 
nagyon fontos, hogy a 2,5 órás beszélgetési időt a program- 
frissítés körülbelül 3—3,5 órára tolja ki. Mindenképpen érdemes 
feltenni a javítást, ugyanis rengeteg SMS-sel kapcsolatos 
gyerekbetegséget is javít. A frissítésről annyit érdemes tudni, 
hogy mindenképpen windowsos felületű gép szükséges hozzá, 
ugyanis egy böhöm nagy .EXE állományba van minden 
belepakolva. A frissítés felülírja a ROM egy részét, és a hasz- 
nálható rendszer memóriából is elvesz nagyjából 1 MB-ot. 
Ennek ellenére az alapprogram-felszereltségről elmondható, 
hogy szegényes. Az ember azt hinné, hogy itt egy remek 
eszköz, amelynél a GSM program csatolón keresztül érhető el, 
és a fejlesztők ezer programot írnak rá. De nem. Ugyan a tele- 
fonkönyv szolgáltatás több lépésben is elérhető, valamint az 
AdressBookból és a SIM memóriából is egy mozdulattal 
tárcsázni tudunk, ennek ellenére például az SMS-küldési 
lehetőségeink meglehetősen kezdetlegesek. A Palm operációs 
rendszerre íródott FUNSMS rengeteg hasznos SMS-küldési, 
illetve -fogadási lehetőséget kínál számunkra, például a Flash 
SMS küldését. Ez olyan SMS, amely a megérkezés pillanatában 
, megnyílik" a fogadó félnél, tehát nem kell megnyitni, illetve 
szinte korlátlanul menthetjük az SMS-eket. A FUNSMS 
programnak is létezik olyan változata, amelyben a Ireo már 
próbaváltozatban támogatott, de sajnos még nem tökéletes, 
infratelefonok és Palm-eszközök között viszont gyönyörűen 
működik. 


GPRS 


Azért, hogy ne csak rosszat írjak a Ireo 180g-ről, el kell mon- 
danom, hogy a frissítés után nagyon kényelmesen lehet róla 
internetezni vagy WAP-oldalakat nézegetni a beépített 
böngésző, illetve a letölthető Wapman program segítségével. 
Nagyon nagy hibája azonban, hogyha például programokat 
töltünk fel a PC-ről a Ireóra, a telefonon nem lehet hívást 
fogadni, mivel a telefon-csatolófelület nem tud középpontba 
kerülni, és ilyenkor a nem fogadott hívások listájában sem 
jelenik meg a hívó, továbbá a készülék foglalt jelzést ad. 


Összegzés 

A Ireo 180g egy Handspring Edge-tudású, 16 MB memóriával 
rendelkező hasznos segítőtárs, de számolni kell azzal a lehető- 
séggel, hogyha a Ireo meghibásodik, akkor se telefon, se titkár. 


Varga S. Csaba (guskaoguska.hu) 

Az 1.1-es Slackware óta linuxozik. Kedvtelései közé 
tartozik a fotózás és a Linux telepítése PDA-kra. 
Legszívesebben a Gerecsében túrázik a barátaival. 





2 http:/Avwwhandspring.hu 


2 http:/Awwwtreogprs.com 

2 http:/Avww.sl451.n[/s145c/ 

lelefonok összekötése Linuxszal (régebbi linuxvilágos 
cikkek) 3 http:/Avww.guska.hu/publication/cikkek/ 
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